hey,
Dr R L Oswald wrote:
Recently, yum installed an updated kernel 2.4.21-32.0.1.ELsmp; when we got around to rebooting, we found that some of the machines were running the uniprocessor kernel 2.4.21-32.0.1.EL , showing only a single cpu.
Easy workaround = just yum erase the UP kernel package, that way the system can only come back with a SMP kernel.
The grub.conf file had been modified in the usual pushdown manner but the default kernel had been set at #2 instead of #0.
Do you have a sample from 'before' the update ? also what version of mkinitrd do you have installed on these machines ? Was that updated at the same time as the kernel ? Also, what does /etc/redhat-release say ?
Here is the grub.conf from an affected server: default=2 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz
Changing the default back to 0 has no effect, it still boots the 2.4.21-32.0.1.EL kernel and not the required SMP one. However, if we use
disable the splashimage, and reboot the machine with default=0, what kernel version is highlighted as the default ?
I tried the obvious ploy of removing the last three kernel entries in grub.conf & setting default=0 but it still manages to boot the 2.4.21-32.0.1.EL UP kernel even though it is no longer in the kernel menu list.
Are you sure the grub.conf you are editing is indeed the one that is being used ? ( should be the /boot/grub/grub.conf file ) What does 'parted <bootdev> print' say ?
We think we will disable automatic yum kernel updates in future , but meanwhile, has anyone any suggestions or experiences to share on this apart from a complete re-install of each affected node?
I would suggest you provide some more info, and also try to reinstall grub. At the very least grub should accomodate changes being made in the /boot/grub/grub.conf file.
fwiw, I've tried to reproduce this issue here on a CentOS3/i386 SMP machine [1] and am unable to do so. The kernel update installs and sets up grub.conf fine.
- K
[1] CentOS 3.4 install and yum update from there.