Bug 1717723 - 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
Summary: after installing a new kernel, the system boots into the old kernel when GRUB...
Keywords:
Status: CLOSED DUPLICATE of bug 1704926
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-06 02:32 UTC by Andrew Schorr
Modified: 2020-01-28 13:30 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-01-28 13:30:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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 ***


Note You need to log in before you can comment on or make changes to this bug.