Bug 1717723

Summary:	after installing a new kernel, the system boots into the old kernel when GRUB_DEFAULT=saved is set, despite having set GRUB_UPDATE_DEFAULT_KERNEL=true
Product:	[Fedora] Fedora	Reporter:	Andrew Schorr <ajschorr>
Component:	grub2	Assignee:	Peter Jones <pjones>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	30	CC:	akarlsso, fmartine, jmontleo, lkundrak, pjones
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-01-28 13:30:06 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andrew Schorr 2019-06-06 02:32:02 UTC

Description of problem:
After installing a new kernel, my system by default boots to the previous kernel, despite my having GRUB_UPDATE_DEFAULT_KERNEL=true in /etc/sysconfig/grub. I also have GRUB_DEFAULT=saved and GRUB_SAVEDEFAULT=true configured because I can dual-boot into Windows, and having selected Windows, I need it to reboot into Windows when applying a series of updates. In Fedora 29 before BLS, this was no problem -- when I installed a new kernel, it would reboot into the new kernel on reboot, despite the GRUB_DEFAULT=saved setting. In Fedora 30 with BLS, it no longer works. I looked in /usr/lib/kernel/install.d/20-grub.install and figured that adding GRUB_UPDATE_DEFAULT_KERNEL=true should fix the problem, but it doesn't.

Version-Release number of selected component (if applicable):
grub2-common-2.02-81.fc30.noarch


How reproducible:
always

Steps to Reproduce:
1. Install new kernel.
2. Reboot. 
3. Notice that it booted into the previous kernel.

Actual results: boots into the previous kernel version.


Expected results: boot into the new kernel!


Additional info:

Comment 1 Andrew Schorr 2019-06-10 15:32:44 UTC

After installing kernel kernel-5.1.7-300.fc30.x86_64, I saw this:

$ diff /var/tmp/grubenv.save /boot/grub2/grubenv
2,4c2,4
< saved_entry=1f879f680f24456d984d5c49ce7475b1-5.1.6-300.fc30.x86_64
< boot_success=1
< boot_indeterminate=1
---
> saved_entry=1f879f680f24456d984d5c49ce7475b1-5.1.7-300.fc30.x86_64
> boot_success=0
> boot_indeterminate=0

So that seems correct. But when I rebooted, grub highlighted the 5.1.6 entry as the default. So
I'm mystified as to what's going wrong here.

Comment 2 Andrew Schorr 2019-08-12 22:20:45 UTC

FYI, I am now having the same problem on a 2nd system.

Comment 3 Andrew Schorr 2019-08-12 22:22:34 UTC

My father just upgraded his PC from F29 to F30, and it rebooted into F30, but is running the F29 kernel!

[hschorr@herb-acer ~]$ rpm -q kernel
kernel-5.1.16-200.fc29.x86_64
kernel-5.1.18-200.fc29.x86_64
kernel-5.2.7-100.fc29.x86_64
kernel-5.2.7-200.fc30.x86_64

[hschorr@herb-acer ~]$ uname -r
5.1.18-200.fc29.x86_64

[hschorr@herb-acer ~]$ cat /etc/sysconfig/grub 
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=/dev/mapper/centos-swap rd.lvm.lv=centos/fedora rd.lvm.lv=centos/swap rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

Comment 4 Jason Montleon 2019-08-13 13:18:14 UTC

FWIW, when I had this problem with an upgraded system, it seemed the /boot/efi/EFI/fedora/grubenv file was somehow suddenly corrupt. I don't know if the format changed between releases or something went wrong during the upgrade process.

I ended up making a backup of the grubenv file and using `grub2-editenv /boot/efi/EFI/fedora/grubenv create` to create a new one. This file will be empty though.

`sudo dnf reinstall -y kernel kernel-core` added back the `saved_entry` line.

grub2-mkconfig -o /etc/grub2-efi.cfg added back the `kernelopts` line

Last note, if you're not using EFI the file names/locations might be slightly different. On my system:
/boot/grub2/grubenv -> ../efi/EFI/fedora/grubenv

Since then upgrades have been working as expected.

Comment 5 Javier Martinez Canillas 2020-01-28 13:30:06 UTC


*** This bug has been marked as a duplicate of bug 1704926 ***