On Jun 14, 2014, at 6:19 PM, Jackson Byers <byersjab(a)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