JohnS wrote:
On Wed, 2010-05-26 at 14:57 -0400, m.roth@5-cent.us wrote:
Bowie wrote:
m.roth@5-cent.us wrote:
Bowie wrote:
<snip>
Once it's on, it's fairly stable... though the update of the kernel does *not* always work correctly. With nearly 200 machines that I'm rolling out updates to, not infrequently, I'll see that the default= line in /etc/grub.conf is reset... to the last kernel,rather than the current, or to the debug kernel. I always have to check to verify that it's pointing correctly before rebooting.
And, in fact, that is exactly what happened. The default= line was set to 1, so it booted the old kernel instead of the new one. Other than that, it seems to be fine. I wonder what causes that? I've never noticed that behavior in my other systems. (But maybe I should go check now...)
I have *no* idea. I've even seen it pointing to 2, or 4. Anyone here have any idea why it wouldn't *always* change the default to 0?
mark
Where did you get the kernel from? There is a reason why I ask this because all installed kernels I have installed that were built by CentOS do the right thing. As in update the boot sequence for you.
The exception is The Upstream Real Time Kernel does not do this and is docoed.
Now the PAE Kernel I can not speak for because I do not use it. I only utilize the pae form for 32 bit under the RT Kernel which pae is built into for 32bits.
The kernel came from the updates repo. I just did "yum update" on a newly installed 5.5 system. The only oddity is that the original grub.conf file was created by hand rather than by anaconda. (Due to anaconda NOT doing "the right thing" when installing from a USB install media)
My theory is that the script that updates grub.conf is somehow detecting that the file is not stock and therefore updating the default= line to avoid changing the active kernel.
I looked through some of my other machines and was not able to find a single one that had anything other than default=0.