Created attachment 1071857 [details] screenshot showing wrong kernel selected by default Description of problem: After dnf upgrade, the old kernel still boots by default. Version-Release number of selected component (if applicable): grubby-8.40-2.fc23.x86_64 How reproducible: Always Steps to Reproduce: 1. Install Fedora-Live-Workstation-x86_64-23_Beta-TC4.iso 2. reboot 3. dnf upgrade 4. reboot Actual results: In GRUB menu, old kernel menu entry is the default. Expected results: In GRUB menu, new kernel entry should be default. Additional info: Anaconda program log shows: 10:33:14,450 INFO program: Running... grub2-install --no-floppy /dev/sda 10:33:15,396 INFO program: Running... grub2-set-default 0 10:33:15,500 INFO program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg And yet after the first boot of the installed system: # grub2-editenv list saved_entry=Fedora (4.2.0-1.fc23.x86_64) 23 (Workstation Edition) Grubby appears to have changed the grubenv to that kernel version at the time of installation, I'm guessing because grubenv was 0. If all I do is rerun grub2-mkconfig -o /boot/grub2/grub.cfg to wipe out the grubby modified grub.cfg, the new kernel is now default.
Created attachment 1071862 [details] grub.cfg after installation
Created attachment 1071863 [details] grub.cfg after kernel upgrade
Reproduces on i686 baremetal and x86_64 VM. I'm not sure why it's happening now, because it's the same version of grubby since April. The suspicious part is the grubenv contents: # grub2-editenv list saved_entry=Fedora (4.2.0-1.fc23.x86_64) 23 (Workstation Edition)
Could it be that GRUB_DEFAULT=saved in /etc/default/grub ? Btw I'm seeing the same issue on Rawhide.
I'm experiencing the same bug in F23. The new installed kernels aren't set as default. But in my case, grub2-mkconfig doesn't make a difference. This is a clean F23-Beta Workstation install with these packages: grub2-tools-2.02-0.23.fc23.x86_64 grub2-2.02-0.23.fc23.x86_64 grubby-8.40-2.fc23.x86_64 grub2-efi-2.02-0.23.fc23.x86_64
This is still a bug, with a clean net install of Workstation I got kernel 4.2.1 and on a subsequent Software update 4.2.3 was installed. But GRUB menu defaults to 4.2.1, the newer kernel is not booted by default.
There is no specific single release criteria that applies, but it's been successfully argued in the past that a new kernel needs to actually boot by default once installed because it could contain security updates and the user may not be aware that the new kernel isn't booting. Beta criteria for updates: "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops." So here I'll argue it's not enough that they're installed, they need to actually be used (which for any other package would be true but the kernel is unique in that multiple versions can exist at the same time). Final criterial for security. "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)." It's uncertain whether this bug can be fixed with an update.
I can't reproduce this. Fresh install of Final TC1 Workstation live (to get a kernel older than the current stable), 'dnf update kernel', reboot, and it boots the newly-installed kernel by default, not the old one. The old one *is* listed in /boot/grub2/grubenv , but nevertheless, grub boots the new one.
Can't reproduce going from Beta to current, either.
(In reply to awilliam from comment #8) Can you attach or post contents of /etc/default/grub ? I wonder if live vs net have different settings that causes this; clearly in your case grubenv is ignored while mine is honored. I'd check this myself but I have 150KB/s Internet in BFE mountains for another couple days.
Hmm, but I can reproduce it with a UEFI install. Not sure what the difference would be there, though. Indeed, install Final TC1 Workstation on UEFI system, 'dnf update kernel', reboot, and you get the TC1 kernel, not the updated kernel.
I don't think /etc/default/grub *does* anything unless you run grub2-mkconfig , does it? grubby doesn't care about it at all. Still, I checked: /etc/default/grub is exactly the same in both BIOS and UEFI installs.
In an F22 install, the saved entry in grubenv is updated when I update the kernel: [root@localhost test]# grub2-editenv /boot/efi/EFI/fedora/grubenv list saved_entry=Fedora (4.0.4-301.fc22.x86_64) 22 (Twenty Two) [root@localhost test]# uname -r 4.0.4-301.fc22.x86_64 [root@localhost test]# dnf update kernel ... Installing : kernel-core-4.1.10-200.fc22.x86_64 ... Complete! [root@localhost test]# grub2-editenv /boot/efi/EFI/fedora/grubenv list saved_entry=Fedora (4.1.10-200.fc22.x86_64) 22 (Twenty Two) so, something's definitely broken there, F23 grubby is not updating the saved entry when it updates the kernel...
So here's a thing: [root@localhost test]# rpm -q --scripts kernel-core-4.2.3-300.fc23.x86_64 ... posttrans scriptlet (using /bin/sh): /bin/kernel-install add 4.2.3-300.fc23.x86_64 /lib/modules/4.2.3-300.fc23.x86_64/vmlinuz || exit $? [root@localhost test]# sh -x /bin/kernel-install add 4.2.3-300.fc23.x86_64 /lib/modules/4.2.3-300.fc23.x86_64/vmlinuz /bin/kernel-install: line 35: syntax error near unexpected token `<' /bin/kernel-install: line 35: ` readarray -t files < <(' seems significant.
oh, never mind that - it fails in 'sh -x' because 'readarray' is a bashism. But still, there's a mystery here: [root@localhost test]# grub2-editenv list saved_entry=Fedora (4.2.0-300.fc23.x86_64) 23 (Workstation Edition) [root@localhost test]# dnf update kernel ... Installing : kernel-core-4.2.3-300.fc23.x86_64 1/3 [root@localhost test]# grub2-editenv list saved_entry=Fedora (4.2.0-300.fc23.x86_64) 23 (Workstation Edition) ... [root@localhost test]# /bin/kernel-install add 4.2.3-300.fc23.x86_64 /lib/modules/4.2.3-300.fc23.x86_64/vmlinuz [root@localhost test]# grub2-editenv list saved_entry=Fedora (4.2.3-300.fc23.x86_64) 23 (Workstation Edition) so somehow when the kernel is first installed, the kernel-install (which calls new-kernel-pkg and ultimately grubby) doesn't updated the saved entry, but running it manually afterwards does...
Aha! I think we may have us a Python 3 issue. /etc/sysconfig/kernel on F23: # UPDATEDEFAULT specifies if new-kernel-pkg should make # new kernels the default UPDATEDEFAULT=yes # DEFAULTKERNEL specifies the default kernel package type DEFAULTKERNEL=b'kernel-core' /etc/sysconfig/kernel on F22: # UPDATEDEFAULT specifies if new-kernel-pkg should make # new kernels the default UPDATEDEFAULT=yes # DEFAULTKERNEL specifies the default kernel package type DEFAULTKERNEL=kernel-core spot the difference. Looks like good ol' py2 vs. py3 string types.
https://github.com/rhinstaller/anaconda/pull/409
I tested that; it works for me. In both BIOS and UEFI cases it causes grubenv to be correctly updated, and it does indeed make the new kernel the default boot option in the UEFI case, for me. https://www.happyassassin.net/updates/1261569.0.img is an updates.img built against anaconda-23.19.6-1.fc23 , which is the version in Final TC6 and TC9, for others to test.
Discussed at 2015-10-15 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-10-15/f23-blocker-review.2015-10-15-20.11.log.txt . Accepted as a blocker per criterion "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops." As we have in the past for a similar issue, we held that kernel updates aren't properly 'installed' if the updated kernel is not the default boot choice, as intended: the practical impact is bad on remote-managed servers where the admin doesn't usually see the boot screen, they expect to be able to simply apply updates and reboot the system to update to the newest kernel.
anaconda-23.19.8-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-cad91ea1ae
anaconda-23.19.8-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update anaconda' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-cad91ea1ae
python-blivet-1.12.8-1.fc23 anaconda-23.19.9-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-da7ada8825
Fixed for me with RC2.
Looks like this issue won't be fixed for already installed F23 installations. Is that correct? How do I manually fix this issue for an existing F23 installation?
Would like to know the same as comment 24.
"Looks like this issue won't be fixed for already installed F23 installations. Is that correct?" Yup. "How do I manually fix this issue for an existing F23 installation?" Edit /etc/sysconfig/kernel and fix the line, as per #c16. That *should* be all that's needed, though I haven't checked. Kernels installed after that point should become the default.
anaconda-23.19.10-1.fc23, python-blivet-1.12.8-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update anaconda python-blivet' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-da7ada8825
Verified with RC3 (on UEFI).
anaconda-23.19.10-1.fc23, python-blivet-1.12.8-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to awilliam from comment #26) > Edit /etc/sysconfig/kernel and fix the line, as per #c16. That *should* be > all that's needed, though I haven't checked. Kernels installed after that > point should become the default. I can't figure out what I need to do here. Also, are all F23 pre-release testers expected to find this bug report on their own?
(In reply to teppot from comment #30) > I can't figure out what I need to do here. I believe you need to change DEFAULTKERNEL=b'kernel-core' to DEFAULTKERNEL=kernel-core > Also, are all F23 pre-release > testers expected to find this bug report on their own? We could add this issue to https://fedoraproject.org/wiki/Common_F23_bugs since it requires manually intervention. I don't have better ideas.
There isn't really anything better we can do, I don't think it's a good idea to ship an update that goes around sed'ing people's config files. As a pre-release tester you are expected to be able to figure stuff like this out, generally speaking - there are enough references to the bug that it should be reasonably simple to google.
(In reply to awilliam from comment #26) > "Looks like this issue won't be fixed for already installed F23 > installations. Is that correct?" > > Yup. > > "How do I manually fix this issue for an existing F23 installation?" > > Edit /etc/sysconfig/kernel and fix the line, as per #c16. That *should* be > all that's needed, though I haven't checked. Kernels installed after that > point should become the default. In addition to the modification of /etc/sysconfig/kernel, the default entry should be set in GRUB, e.g. according to: https://fedoraproject.org/wiki/GRUB_2#Setting_default_entry Doing this, the default entry is set immediately and security is ensured. Otherwise it would take until there is the next update to the kernel ...
There is still something screwy going on with grubenv, where "grub2-editenv list" after a recent kernel update shows the previous kernel version. I had set this to 0 previously, but something is changing it, and changing it incorrectly.
I had the same error. "cat /etc/system-release fedora release 23 but uname -r fc22" I have two disk on my laptop and others Linux distributions. The boot sequence of the two discs was generated by other Linux distributions. I started on the distribution that generated the file, and I restarted the laptop. Everything is in order. Hope this can help. Best regards. Kaan.