yum update from 3.14.4 looks ok, but still stuck 3.14.4-200.fc20.x86_64

[Chris Murphy]

On Jun 14, 2014, at 6:19 PM, Jackson Byers <byersjab at gmail.com> wrote:

> yum update from 3.14.4 looks ok
> in /boot 
> vmlinuz-3.14.3-200.fc20.x86_64
> vmlinuz-3.14.4-200.fc20.x86_64
> vmlinuz-3.14.7-200.fc20.x86_64
> 
> I can't seem to get 3.14.7 to 'take'
> after reboot still in 3.14.4
> 
> exact command used for update:
> 
> yum update && grub2-mkconfig -o /boot/grub2/grub.cfg

I'm not sure what sequence this translates into. I'm pretty sure yum only completes once rpm completes, and rpm includes running new-kernel-pkg which runs grubby which is what updates the grub.cfg. But is it possible that grub2-mkconfig runs before all child processes of yum are done?

Anyway this is not the correct command to run. What I'd like to see is the grub.cfg before running yum update, and after. That grub2-install fixed it makes me wonder if there was grubenv corruption (?) which is responsible for the default entry to boot, maybe grub2-install is resetting grubenv.

Normally you do not need to do a grub2-mkconfig after a kernel update, let alone a grub2-install. If you are, it's a bug, so open one up and post as much info you can including the results from bootinfoscript off sourceforge. The CentOS folks also have a script that will collect basic information like this for troubleshooting. The one case I'm aware of where we have to run grub2-mkconfig after each kernel update is if /boot is on a Btrfs subvolume, and that's because grubby doesn't yet understand subvolumes (patch is upstream finally, yay!).

Chris Murphy