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] -----------------------------------------------------------------