Page 1 of 1

Grub won't boot new kernel

Posted: 2018/01/08 10:13:48
by miraclemaker
I'm trying to update the kernel on my dedicated CentOS 6.9 server but after rebooting it's still loading the old kernel.

uname -a gives:
2.6.32-696.6.3.el6.x86_64 #1 SMP Wed Jul 12 14:17:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Here is the contents of /etc/grub.conf:

Code: Select all

default=0
timeout=5
splashimage=(hd0,1)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.32-696.18.7.el6.x86_64)
        root (hd0,1)
        kernel /vmlinuz-2.6.32-696.18.7.el6.x86_64 ro root=/dev/mapper/VolGroup00-LogVol00 rd_NO$
        initrd /initramfs-2.6.32-696.18.7.el6.x86_64.img
title CentOS (2.6.32-696.16.1.el6.x86_64)
        root (hd0,1)
        kernel /vmlinuz-2.6.32-696.16.1.el6.x86_64 ro root=/dev/mapper/VolGroup00-LogVol00 rd_NO$
        initrd /initramfs-2.6.32-696.16.1.el6.x86_64.img
title CentOS (2.6.32-696.13.2.el6.x86_64)
        root (hd0,1)
        kernel /vmlinuz-2.6.32-696.13.2.el6.x86_64 ro root=/dev/mapper/VolGroup00-LogVol00 rd_NO$
        initrd /initramfs-2.6.32-696.13.2.el6.x86_64.img
title CentOS (2.6.32-696.10.3.el6.x86_64)
        root (hd0,1)
        kernel /vmlinuz-2.6.32-696.10.3.el6.x86_64 ro root=/dev/mapper/VolGroup00-LogVol00 rd_NO$
        initrd /initramfs-2.6.32-696.10.3.el6.x86_64.img
title CentOS (2.6.32-696.6.3.el6.x86_64)
        root (hd0,1)
        kernel /vmlinuz-2.6.32-696.6.3.el6.x86_64 ro root=/dev/mapper/VolGroup00-LogVol00 rd_NO_$
        initrd /initramfs-2.6.32-696.6.3.el6.x86_64.img
So it seems to be skipping over the four newer kernels before loading 2.6.32-696.6.3

I'm keen to get this sorted because of Meltdown / Spectre.

Many thanks.

Re: Grub won't boot new kernel

Posted: 2018/01/08 12:11:28
by TrevorH
If you are having problems with grub such as new kernels not being detected you should check the symlink exists between /etc/grub.conf -> ../boot/grub/grub.conf

Also, if your system runs a linux software RAID 1 /boot, check the contents of /proc/mdstat to make sure the array is healthy.

Re: Grub won't boot new kernel

Posted: 2018/01/09 09:24:15
by miraclemaker
Thanks for taking the time to reply Trevor. Yes the symlink is in place.

/proc/mdstat gives:

Code: Select all

Personalities : [raid1]
md0 : active raid1 sdb2[1]
      524224 blocks super 1.0 [2/1] [_U]

md1 : active raid1 sdb3[1]
      1950760960 blocks super 1.1 [2/1] [_U]
      bitmap: 13/15 pages [52KB], 65536KB chunk

unused devices: <none>
which looks ok?
/boot also has ~300MB free disk space so I don't think it's an issue due to running out of space on /boot.

Re: Grub won't boot new kernel

Posted: 2018/01/09 12:56:13
by TrevorH
No, your RAID is broken. See the fields like "[_U]" show that the first device is missing from the array on both md0 and md1. That's enough to explain your problem. The BIOS is booting from the "missing" drive which is out of date. The system boots, finds both drives, realises the non-boot drive is more up to date and uses that as the main RAID device and kicks the out of date one. Your kernel updates are on /dev/sdb but not on the other disk.

You'll need to re-add the missing partitions back into the RAID device and let it rebuild.

Re: Grub won't boot new kernel

Posted: 2018/01/09 14:46:55
by miraclemaker
Ah I see! Many thanks for the help here. I will do some research on fixing the RAID array, and I'll be back on this excellent forum if I run into any further problems.

Thanks again for your help!

Re: Grub won't boot new kernel

Posted: 2018/01/10 09:06:36
by miraclemaker
Just a note to say that the drive missing from the RAID array had failed so I had the hosting company replace it over night. Booting from the good drive meant that the new kernel has loaded correctly, and the RAID array is in the process of rebuilding on the new drive:

uname -a:
2.6.32-696.18.7.el6.x86_64 #1 SMP Thu Jan 4 17:31:22 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

cat /proc/mdstat:

Code: Select all

Personalities : [raid1]
md0 : active raid1 sda2[2] sdb2[1]
      524224 blocks super 1.0 [2/2] [UU]

md1 : active raid1 sda3[2] sdb3[1]
      1950760960 blocks super 1.1 [2/1] [_U]
      [==>..................]  recovery = 13.7% (267928896/1950760960) finish=183.4min speed=152848K/sec
      bitmap: 12/15 pages [48KB], 65536KB chunk
Many thanks for your help Trevor!