[CentOS] how long to reboot server ?

Keith Roberts keith at karsites.net
Sat Sep 4 14:14:07 UTC 2010


On Fri, 3 Sep 2010, Ross Walker wrote:

> To: CentOS mailing list <centos at centos.org>
> From: Ross Walker <rswwalker at gmail.com>
> Subject: Re: [CentOS] how long to reboot server ?
> 
> On Sep 3, 2010, at 4:10 PM, Marko Vojinovic <vvmarko at gmail.com> wrote:
>
>> On Friday, September 03, 2010 18:34:51 Matthew Miller wrote:
>>> On Fri, Sep 03, 2010 at 12:17:37PM -0500, Les Mikesell wrote:
>>>> Does anyone know if this is special-cased or some config setting?  I
>>>
>>> It's special-cased.
>>
>> I remember the discussion on the Fedora-list about this a very long time ago,
>> and the bottomline is roughly the following:
>>
>> * when a yum update installs a new kernel, it checks if the total number of
>> installed kernels exceeds the installonly_limit parameter
>> * if not, everything is ok
>> * if yes, the oldest *non-running* kernel is removed and the remaining number
>> of kernels is checked again against installonly_limit, and the removal step is
>> repeated if they still don't match up.
>>
>> This was done precisely because it was understood that a currently running
>> kernel can be assumed to be stable and bootable. So if you have several
>> kernels, run a yum update while the oldest one is running, get a new kernel,
>> the extra kernels that will get removed are those "in between". This ensures
>> that with any multiple-kernel configuration of yum, there will be at least one
>> kernel known to work, as a failsafe.
>>
>> I believe CentOS just inherited this behavior of yum. Though I might be wrong,
>> it seems unlikely that anyone would remove this feature from yum on purpose.
>>
>> So all in all, you should never be afraid that yum will leave you only with
>> untested kernels while updating.
>
> This is good info!
>
> What I am wondering is if there is a way to prevent new 
> kernels from becoming the default by... default?
>
> That way one won't be "pleasantly" surprised that after a 
> long uptime and several updates, that on the next reboot 
> their applications stop working because of a kernel update 
> that hadn't been tested yet.
>
> A way where the admin must manually choose the default kernel.
>
> -Ross

I have 2 root partitions labelled Fedora-8-root and 
Fedora-12-root, and have installed GRUB to a seperate boot 
partition, labelled GrubBoot. ~20MB should be plenty for a 
boot partition, maybe less than that. GrubBoot is a 
logical partition in the extended partition.

There are no symlinks to grub.conf on my active root 
partition. the /boot/grub/ directory only contains the 
splash.xpm.gz image (which probably doesn't need to be 
there anyway).

Whenever there is a kernel upgrade, yum installs the kernel 
files to the active root partition. As the GrubBoot 
partition is not mounted, the kernel rpm scripts cannot find 
the grub.conf file to modify it, so that remains the same.

I have had this problem on SuSE when I had to compile the 
kernel with the Nvidia graphics driver after the kernel was 
upgraded. IIRC there was only one kernel installed at a 
time, so if it did not boot - hard luck!

There have been some recent kernel upgrades on Centos 5.5 
and F12, but I have not even bothered to edit my 
grub.conf file and boot them yet!

See the man page for grub-install how to do this. It's 
really easy and worth the hassle to set up a seperate boot 
partition.

The other bonus is once you have a seperate boot partition 
you can do a fresh install of Linux to a root partition, and 
if you select the 'Do not install GRUB bootloader' option, 
you will still have a working GRUB installation to boot from 
on the GRUB boot partition. That saves some hassle as well.

This is on bare hardware, as I do not do VM's ATM.

HTH

Keith Roberts

-----------------------------------------------------------------
Websites:
http://www.karsites.net
http://www.php-debuggers.net
http://www.raised-from-the-dead.org.uk

All email addresses are challenge-response protected with
TMDA [http://tmda.net]
-----------------------------------------------------------------



More information about the CentOS mailing list