On Fri, 3 Sep 2010, Ross Walker wrote:
> To: CentOS mailing list <centos@xxxxxxxxxx>
> From: Ross Walker <rswwalker@xxxxxxxxx>
> Subject: Re: how long to reboot server ?
>
> On Sep 3, 2010, at 4:10 PM, Marko Vojinovic <vvmarko@xxxxxxxxx> 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]
-----------------------------------------------------------------
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
