When to update RHEL kernels?
Nico Kadel-Garcia
permission to post publicly here. ]
[ Name deleted to protect the innocent ]
> Hi Nico,
>
> Hope all is going well mate.
>
> I have a quick question.. do you regularly update linux kernels. .or wait
> for major releases?
> We are still on: kernel-PAE-2.6.18-92 and the current version
> kernel-PAE-2.6.18-128 is:
>
> I was planning on updating when version 5.3 is released. what do you think
> is good practise?
This is a good general question, and belongs over on the Usenet
newsgroup comp.os.linux.setup. Feel free to ask this sort of thing
there, so you get more opiniions than mine, because they differ and
for good reason. I'd like permission to put this discussion there,
maybe with your name scraped off and your current kernel practices
snipped.
Kernel updates require reboots: that's an old problem that lots of
people have looked at and never provided a better solution in the UNIX
or Linux world. (Minix has a fascinating approach to this, but it's
too late for that now.) I like to edit grub.conf to turn off the
"splashimage" and 'hiddenmenu" options and up the timeout, which also
helps for remote serial port or virtualization or KVM management
because those traditionally are VNC based which makes very, very slow
keyboard interactions while selecting your new or old kernels at boot
time. It's not as big a deal in a small, local environment where you
can do hands on, but for remote Dell DRAC card or in a remote disaster
recovery site, it's a big deal to have that set up first before
discussing kernel updates.
RHEL 5.3 has been out for a while, hasn't it? It's certainly been out
for CentOS, and any RHEL system that's merely been kept up to date has
*everything* that's in 5.3. RHEL's current minor releases provide new
installation media and include a stack of the updates already included
to ease installation. They're not the big deal that old RedHat OS
updates were. back in ther RedHat 7.1, 7.2, 7.3 days.They're very
useful for installing new hardware that wasn't supported by previous
minor release kernels or installers.
The RedHat Network service gives good warnings on required updates for
your registered machines, especially kernels. This is also good
warning for spare CentOS operating systems: If there are good
"critical" updates listed that I care about such as serious crashing
bugs or memory leaks or security bugs for services that I have exposed
to only semi-secure internal networks or DMZ machines, then I like to
update them regularly. And I like to reboot regularly (say, once every
3 months for a critical server) to kick old idle processes and users
the heck off, and to ensure that the machine *CAN* reboot. (You
remember that absolute !@#$ we ran into when a core switch had to be
rebooted in a rush, the backups I was assured existed did not in fact
exist, and the hardware was in fact screwed and did not reboot.)
Reliable rebooting, like bare metal re-installation, is a maintenance
task that is often ignored and can be hellish to try and fix in an
emergency. Since you're in a position to set such policies, I'd
suggest scheduling "once every 60 days" or so.
Doug Freyburger
For most hosts I like to update the yum repository quarterly
and apply the non-rebooting RPMs. I like to schedule the
rebooting ones a couple of times per year with the standard
march through the dev, test and prod environments on
sequential weekends.
When I try that on my few hosts running Oracle OCFS2 I
have found that the kernel is updated much more often than
the OCFS2 RPMs and that OCFS2 is extremely touchy
about exact kernel rev levels. I've even downloaded RPMs
and ended up with the installation process complaining
about an extra clause in the long strings of number dot
number dot number.
Does anyone have a good way to handle OCFS2 upgrades?
I could open a sev 3 Oracle SR on the support contract but
I figure anyone here who has addressed the issue will be
quicker than that path.
Nico Kadel-Garcia
Besides using MySQL instead, or maybe SQLite for lighter databases? If
you're stuck with it, though, I'd link the kernel upgrades to OCFS2
RPM updates directly. There are some good yum utilities for doing
precisely this and blocking surprise updates.