Description of problem: Lately, installing a new kernel, leaves the old kernel as the default. Selecting the new kernel instead is not saved by grub as the next boot default. Version-Release number of selected component (if applicable): [cornel@localhost ~]$ rpm -q kernel-PAE kernel-PAE-3.16.0-1.fc21.i686 [cornel@localhost ~]$ rpm -qa | grep -i grub grub2-tools-2.02-0.6.fc21.i686 grub2-2.02-0.6.fc21.i686 grubby-8.35-3.fc21.i686 How reproducible: always Steps to Reproduce: 1.install new kernel and reboot 2.boot new kernel 3.reboot Actual results: after reboot, old kernel is still the default Expected results: Additional info:
grub2-set-default works around this, but this is unexpected for any typical computer user.
Something is modifying the grubenv setting for this, I'm not sure yet what's doing it. 1. Anaconda commit 5c26c8689bc55e3c5fadc74cfa3636475cb54b1a "change default for grub2 save_entry to 0" causes anaconda to use "grub2-set-default 0" just before grub2-mkconfig. 2. $ grub2-editenv list saved_entry=0 3. $ dnf reinstall kernel-core $ grub2-editenv list saved_entry=Fedora, with Linux 3.16.0-1.fc21.x86_64+debug I'm going to guess this is actually a grubby bug which is called when doing kernel installs. 4. # grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg Generating grub configuration file ... Found linux image: /boot/vmlinuz-3.16.0-1.fc21.x86_64+debug Found initrd image: /boot/initramfs-3.16.0-1.fc21.x86_64+debug.img Warning: Please don't use old title `Fedora, with Linux 3.16.0-1.fc21.x86_64+debug' for GRUB_DEFAULT, use `Advanced options for Fedora>Fedora, with Linux 3.16.0-1.fc21.x86_64+debug' (for versions before 2.00) or `gnulinux-advanced-f8e05238-c87e-40a5-9b12-44ecb0b384dc>gnulinux-3.16.0-1.fc21.x86_64+debug-advanced-f8e05238-c87e-40a5-9b12-44ecb0b384dc' (for 2.00 or later) Found linux image: /boot/vmlinuz-3.16.0-1.fc21.x86_64 Found initrd image: /boot/initramfs-3.16.0-1.fc21.x86_64.img Found linux image: /boot/vmlinuz-3.16.0-0.rc7.git4.1.fc21.x86_64 Found initrd image: /boot/initramfs-3.16.0-0.rc7.git4.1.fc21.x86_64.img Found linux image: /boot/vmlinuz-0-rescue-b0aca36644e746269d6c6c929d9b707e Found initrd image: /boot/initramfs-0-rescue-b0aca36644e746269d6c6c929d9b707e.img done So whatever is modifying grubenv, it's not only got the wrong information going in it, it's doing it wrong also. I don't even understand why it's being modified. The saved_entry=0 is valid and shouldn't be second guessed. This is arguably a semi-silent, or at least non-obvious, security bug because kernel updates not being used by default risks stale kernels being used ... at least until yum removes them, and then I'm not sure how this behavior changes, if the system eventually becomes unbootable?
OK so the instigating scriptlet is: + /sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --update 3.16.0-1.fc21.x86_64 If I grub2-set-default 0, confirm it's set, then run that command, it becomes unset. Using bash -x I find this grubby command being used: + /sbin/grubby --grub2 -c /boot/efi/EFI/fedora/grub.cfg --efi --update-kernel=/boot/vmlinuz-3.16.0-1.fc21.x86_64 --initrd /boot/initramfs-3.16.0-1.fc21.x86_64.img '--args= LANG=en_US.UTF-8' # grub2-set-default 0 # grub2-editenv list saved_entry=0 # /sbin/grubby --grub2 -c /boot/efi/EFI/fedora/grub.cfg --efi --update-kernel=/boot/vmlinuz-3.16.0-1.fc21.x86_64 --initrd /boot/initramfs-3.16.0-1.fc21.x86_64.img '--args= LANG=en_US.UTF-8' # grub2-editenv list saved_entry=Fedora, with Linux 3.16.0-1.fc21.x86_64+debug So yeah, it's a grubby problem.
OK I see what's going on. Grubby is looking at grubenv, sees "saved_entry=0" finds the first entry in grub.cfg, and then writes a new "saved_entry=" into grubenv based on the title of that first entry in the grub.cfg. I don't really understand what the value is in changing it; grub2-mkconfig considers the prose to be deprecated. But now I'm not sure why the original poster is having a problem, unless the grub.cfg is somehow messed up. I tried grub2-editenv create to wipe out the existing grubenv, and grubby doesn't modify grubenv in that case. Regression testing back to grubby-8.31, it behaves the same with the anaconda commit mentioned earlier, so I think the anaconda commit is what's started this.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.