Subject: | |
From: | |
Reply To: | |
Date: | Sun, 17 Feb 2013 11:57:28 -0500 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
On Sun, Feb 17, 2013 at 7:54 AM, Mahmood Naderan <[log in to unmask]> wrote:
> Thanks. The problem is the available package is kernel-devel.x86_64
> (2.6.32.279.22.1.el6)
> while my kernel is 2.6.32.279.5.1.el6
>
> Regards,
> Mahmood
As long as your kernels are coming from the normal CentOS
repositories, you should be able to do this:
rpm -q kernel-devel-`uname -r` # indicates if you have correct
kernel-devel for current kernel
yum install kernel-devel-`uname -r` # installs it if needed
And yeah, updating kernels does not actuallly start *running* the new
kernel until after a reboot. This is actually an old problem with many
types of kernel of many operating systems, and is why the ancestor
kernel to Linux (the old "mach" kernel) used a microkernel that was
supposed to be very stable, with modules for networking, disk
controllers, etc. that could be replaced on the fly. It's never worked
well to do that kind of "on-the-fly" replacement of critical systems,
so the Linux kernel winds up requiring reboots to replace.
It also leaves an adventure if you install the updated kernel and
reboot with it without installing the updated kernel-devel package.
Most good drivers these days will auto-rebuild when the system boots
with the new kernel, but there have been many exceptions over the last
decade, most of which I somehow seemed to find in critical systems.
This is particularly an adventure when critical hardware requires hand
installation of kernel modules, such as old Promise IDE RAID
controllers with the "/" partition on them, and with all NVidia
published drivers, and when the update and installation scripts were
written by monkeys who were actually working on Hamlet. (See the above
mentioned NVidia and Promise drivers.)
|
|
|