Bug 1704926

problem hits me at least on 2 systems also

Windows entries still have "savedefault" in their section, while Linux *.conf entries in /boot/loader/entries/ misses that...but a manual adding per conf-file won't work, option looks like ignored if appended, and whole entry is ignored in case of put as first line.

imho blscfg developers must be involved and tell, how they (hopefully) implemented the "savedefault" feature for Linux entries into blscfg and how to trigger the enabling.

Until the bug is fixed we can resort to this for getting back to linux after a detour to Windows:

# grub2-set-default 0

where 0 means the top entry in the list of the boot options, usually the last linux kernel.

I have to say that the GRUB_ENABLE_BLSCFG feature has been a pretty bad experience for me. I have already reported the issue with missing grub entries in Bug 1707199 which has still gotten no attention.  And now I'm running into this issue as well where the last selected boot is not getting saved as the default.

This is fixed for me with a recent FC30 upgrade.

(In reply to Mirko Predosin from comment #5)
> This is fixed for me with a recent FC30 upgrade.

Unfortunately, that's not the case with my FC30.

Could you provide the package list of your upgrade?

PK

(In reply to Mirko Predosin from comment #5)
> This is fixed for me with a recent FC30 upgrade.

This is not fixed, the behavior for me is the exact same as how I reported it.

I'm having "grub2-set-default 0" to enforce the default of booting the most recently installed Linux kernel, because it defaults back to Windows 10 every time the kernel is upgraded.  Is this the same bug, or shall I open another?

I do not experience that behavior, but I have GRUB_SAVEDEFAULT=true and GRUB_DEFAULT=saved commented out while this bug exists to avoid unwanted boots to Windows.  The primary reason why I want to have this work with those options enabled is because of Windows updates - those updates often reboot during the update process and I want it to stay in Windows for that without me babysitting the update.

I believe the fix for me was installing the grubby-deprecated package.

More details are explained here:
https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault

(In reply to Mirko Predosin from comment #10)
> I believe the fix for me was installing the grubby-deprecated package.
> 
> More details are explained here:
> https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault

This did restore the old functionality for me.

This bug is not resolved though, installing a deprecated package (grubby) and disabling BootLoaderSpec is only a temporary band-aid.  To resolve this bug, one of the following must happen:

The functionality from setting GRUB_SAVEDEFAULT must work with BootLoaderSpec and without grubby; or
The functionality from setting GRUB_SAVEDEFAULT must work by removing BootLoaderSpec as the default and continued maintenance of grubby.

This also hit me as I also switched my RAID layout with the upgrade to Fedora 30 and the initrd of F29 was not able to boot my system, but after every kernel upgrade, always the last entry (f29 kernel) was selected and broke my reboot! Besides the obvious fix of removing all f29 kernels I also switched off BLS as it always started the OLDEST Kernel instead of the latest, which is not good for many people when thinking about critical kernel fixes or even computers that miss critical security fixes!

J

Sorry about the last message. It was sent by mistake.

The problem still persists in Fedora 31. I wonder when it would be fixed. For now I have commented out GRUB_ENABLE_BLSCFG=true and running grub2-mkconfig after every kernel update.

Ok, a recent update changed my /etc/default/grub to forcefully add back GRUB_ENABLE_BLSCFG=true, completely breaking the grub config for the next boot.  Look, I get it, you want to switch to BootLoaderSpec but right now it isn't ready unless it incorporates all of the previous functionality or said functionality is officially deprecated.

Can we get at least a simple acknowledgement that you have seen this bug?

(In reply to Arpan Biswas from comment #14)
Yes, the problem persists. I'm using the same workaround

(In reply to jshatch from comment #15)
> Ok, a recent update changed my /etc/default/grub to forcefully add back
> GRUB_ENABLE_BLSCFG=true, completely breaking the grub config for the next
> boot.  Look, I get it, you want to switch to BootLoaderSpec but right now it
> isn't ready unless it incorporates all of the previous functionality or said
> functionality is officially deprecated.
> 
> Can we get at least a simple acknowledgement that you have seen this bug?

Yes, I agree that it's an issue and that GRUB_SAVEDEFAULT=true should be honored with GRUB_ENABLE_BLSCFG=true. I'll try to take a look to this next week.

Created attachment 1649822 [details]
Patch which fixes the bug

The attached patch fixes this bug by introducing an optional parameter "savedefault" to the blscfg command. If specified, this adds an invocation of savedefault in all generated entries. The corresponding /etc/grub.d/10_linux then simply adds this parameter if GRUB_SAVEDEFAULT is true. Tested here on fc30.

Please review/apply this patch.

Created attachment 1651705 [details]
Improved patch for fc30

Attached is an improved patch which fixes the bug.

Note: In order to use the "savedefault" functionality, one *MUST* run *BOTH*
grub2-mkconfig and grub2-install once after upgrading the the grub2 package.

With the old patch, failing to run grub2-install but running grub2-mkconfig leads to an unpopulated (empty) boot menu. In order populate the menu, one must open the grub cmdline and run blscfg without any parameter. The new patch uses a grub environment variable instead of a cmdline parameter. Therefore it is backwards compatible to the unpatched grub and the empty menu case cannot happen anymore.

Cheers
 -Fritz

Created attachment 1651706 [details]
Improved patch for fc31 (grub2-1:2.02-104)

The above patch does not apply properly to grub2-1:2.02-104 from fc31.
Therefore, this the proper patch to use with that version.
Functionality is the same.

Cheers
 -Fritz

(In reply to Fritz Elfert from comment #20)
> Created attachment 1651705 [details]
> Improved patch for fc30
>
> Attached is an improved patch which fixes the bug.

Thanks a lot for the patch!

[snip]

> must open the grub cmdline and run blscfg without any parameter. The new
> patch uses a grub environment variable instead of a cmdline parameter.
> Therefore it is backwards compatible to the unpatched grub and the empty
> menu case cannot happen anymore.
>

Agreed that an env var is a much better approach. Your change looks good to me, I'll do a build for F30, 31 and Rawhide including your fix today. I'll just rename the env var name to save_default instead of bls_savedefault so it's consistent with the other env vars used by the blscfg module that don't have a bls_ prefix.
 
> Cheers
>  -Fritz

Best regards

(In reply to Fritz Elfert from comment #21)
> Created attachment 1651706 [details]
> Improved patch for fc31 (grub2-1:2.02-104)
> 

Thanks again for the patch.

Besides the env var name, I've also changed a little bit so the variable is set in grubenv rather than in the GRUB config file so is consistent with the other variables used by the blscfg module. I've also added a commit message and made you the author of the patch, you can see the resulting here:

https://src.fedoraproject.org/rpms/grub2/c/89bc295877ee

I just did a build for Rawhide and pushed updates for Fedora 30 and 31.

Ok guys, fetch the builds, test and give karma here:

For F30: https://bodhi.fedoraproject.org/updates/FEDORA-2020-e3adf88ba7
For F31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-95abadb310

Both look good for me.

Cheers
 -Fritz

grub2-2.02-105.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-95abadb310

grub2-2.02-88.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-e3adf88ba7

Behavior has changed, but still is not correct.  After installing from the testing repository and running grub2-mkconfig, nothing changed (as I expected).  After running dnf upgrade to install a new kernel, the behavior changed.  Now the latest kernel is always selected; booting from either an older kernel or an os-prober-generated entry seems to ignore SAVEDEFAULT.  Is there something else I should be doing to make this work?

(In reply to ghborrmann from comment #27)
> Behavior has changed, but still is not correct.  After installing from the
> testing repository and running grub2-mkconfig, nothing changed (as I
> expected).  After running dnf upgrade to install a new kernel, the behavior
> changed.  Now the latest kernel is always selected; booting from either an
> older kernel or an os-prober-generated entry seems to ignore SAVEDEFAULT. 
> Is there something else I should be doing to make this work?

It's a legacy BIOS install? If so then you need to run grub2-install as Fritz mentioned.

@ghbormann: You missed my note in comment #20:

run:

 grub2-install /dev/WhateverYourBootDeviceIs

Background: There are **two** parts involved:

1. grub2-mkconfig which sets up /boot/grub2/grubenv
2. The actual blscfg new module, which interprets the environment and generates the menuentries.
The latter one gets updated by grub2-install.

Cheers
 -Fritz

*** Bug 1708455 has been marked as a duplicate of this bug. ***

grub2-install resulted in an error, apparently because grub2-efi-x64-modules was not installed.  After installing that from testing, I received the following error message: 

    grub2-install: error: efibootmgr failed to register the boot entry: Unknown error 21928.

If this command is run again, it fails identically except that the unknown error number is different.

At this point, I don't know what to do next.  Since grub2-efi-x64-modules was not installed by anaconda, does this mean that grub requires a target of i386-pc instead of x86_64-efi?  I am reluctant to try this, for fear that this could completely destroy my ability to boot.  Any suggestions?

I just installed the update then reran grub2-mkconfig and it worked.  I'm also using an EFI system though.

After I installed the testing update and ran grub2-mkconfig savedefault works properly.

My previous custom kernel command line options (set via grubby) were missing after doing this. I reenabled them via grubby without further issue. Was this inherent to the update process, or an unintended side effect?

(In reply to ghborrmann from comment #31)
> grub2-install resulted in an error, apparently because grub2-efi-x64-modules
> was not installed.  After installing that from testing, I received the
> following error message: 
> 
>     grub2-install: error: efibootmgr failed to register the boot entry:
> Unknown error 21928.
> 
> If this command is run again, it fails identically except that the unknown
> error number is different.
> 
> At this point, I don't know what to do next.  Since grub2-efi-x64-modules
> was not installed by anaconda, does this mean that grub requires a target of
> i386-pc instead of x86_64-efi?  I am reluctant to try this, for fear that
> this could completely destroy my ability to boot.  Any suggestions?

You should only use grub2-install if you are not using EFI, since for EFI the grub2 binary is updated in the ESP when a new grub2 package is installed.

In the case of EFI you only need to execute grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg to re-generate the GRUB config file.

(In reply to voyde from comment #33)
> After I installed the testing update and ran grub2-mkconfig savedefault
> works properly.
> 
> My previous custom kernel command line options (set via grubby) were missing
> after doing this. I reenabled them via grubby without further issue. Was
> this inherent to the update process, or an unintended side effect?

If you want your kernel cmdline changes to persist across grub2-mkconfig invocations, then you need to modify GRUB_CMDLINE_LINUX in /etc/default/grub.

*** Bug 1717723 has been marked as a duplicate of this bug. ***

grub2-2.02-88.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

grub2-2.02-105.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

I've made a clean Installation of Fedora yesterday and updated all before trying to config anything.
Then i tried to customize GRUB.
It seems like this bug still happens.

This bugfix seems like it doesn't work.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-95abadb310

If BootLoaderSpec is the problem, do you know any workaraound to make Fedora use a non-BootLoaderSpec way?.

Here is kind of workaraound using grubby-deprecated libraries.
https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault#Upgrade.2Fcompatibility_impact

(In reply to thechexmo from comment #39)
> Here is kind of workaraound using grubby-deprecated libraries.
> https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault#Upgrade.
> 2Fcompatibility_impact


That lastly broke my grub and i can't repair it.
I had to boot using a booteable usb tool, but grub2-mkconfig saves something but then grub doesn't work. Grub-install gives me an error about a .sh file missing.

(In reply to thechexmo from comment #39)
> I've made a clean Installation of Fedora yesterday and updated all before
> trying to config anything.
> Then i tried to customize GRUB.
> It seems like this bug still happens.
> 
> This bugfix seems like it doesn't work.
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-95abadb310
>

Which Fedora version did you install? Also, is this an EFI or legacy BIOS install?

I assume that you installed Fedora, then added GRUB_SAVEDEFAULT=true to /etc/default/grub and finally re-generated your GRUB config with grub2-mkconfig but GRUB doesn't save as default your last booted entry?

Could you please share the following files:

/boot/grub2/grubnev
/boot/grub2/grub.cfg if your install is a legacy BIOS or /boot/efi/EFI/fedora/grub.cfg if your install is EFI.
/etc/default/grub
/boot/loader/entries/*.conf
 
> If BootLoaderSpec is the problem, do you know any workaraound to make Fedora
> use a non-BootLoaderSpec way?.
> 
> Here is kind of workaraound using grubby-deprecated libraries.
> https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault#Upgrade.
> 2Fcompatibility_impact


Yes, setting GRUB_ENABLE_BLSCFG=false and re-generating your GRUB config file. But in that case you need to install the grubby-deprecated package.

(In reply to thechexmo from comment #40)
> (In reply to thechexmo from comment #39)
> > Here is kind of workaraound using grubby-deprecated libraries.
> > https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault#Upgrade.
> > 2Fcompatibility_impact
> 
> 
> That lastly broke my grub and i can't repair it.
> I had to boot using a booteable usb tool, but grub2-mkconfig saves something
> but then grub doesn't work. Grub-install gives me an error about a .sh file
> missing.

Could you please be more specific on what break? If you have an EFI install then you shouldn't execute grub2-install.

I'm still seeing problems.
Fedora 32, EFI, 64 bit, multiple machines.

grub2-common-2.04-19.fc32.noarch
grub2-efi-x64-2.04-19.fc32.x86_64
grubby-8.40-40.fc32.x86_64
grub2-tools-2.04-19.fc32.x86_64
grub2-tools-extra-2.04-19.fc32.x86_64
grub2-pc-modules-2.04-19.fc32.noarch
grub2-tools-minimal-2.04-19.fc32.x86_64
grub2-efi-x64-cdboot-2.04-19.fc32.x86_64
grub2-starfield-theme-2.02-0.40.fc26.x86_64
grub2-tools-efi-2.04-19.fc32.x86_64
grub2-pc-2.04-19.fc32.

in /etc/default/grub:

GRUB_DEFAULT="saved"
GRUB_SAVEDEFAULT="true"
GRUB_DISABLE_SUBMENU="true"
GRUB_DISABLE_RECOVERY="false"
GRUB_ENABLE_BLSCFG=true


I re-ran grub2-mkconfig and grub2-editenv to clear everything out.

But here's the problem: Once I boot into Windows once, no matter what I boot into later, the default in the environment file stays stuck on that Windows option:

# grub2-editenv list
boot_success=1
boot_indeterminate=0
saved_entry=osprober-efi-E226-CF46

That last saved_entry is the Windows boot loader.
So I have to re-set the grub2 environment file, or it boots into Windows by default even after I boot into Linux again.
I see this behavior on two different machines.
Both were upgraded from Fedora 31.

(In reply to Garrett Mitchener from comment #43)

[snip]

> 
> in /etc/default/grub:
> 
> GRUB_DEFAULT="saved"
> GRUB_SAVEDEFAULT="true"
> GRUB_DISABLE_SUBMENU="true"
> GRUB_DISABLE_RECOVERY="false"
> GRUB_ENABLE_BLSCFG=true
> 
> 
> I re-ran grub2-mkconfig and grub2-editenv to clear everything out.
>
> But here's the problem: Once I boot into Windows once, no matter what I boot
> into later, the default in the environment file stays stuck on that Windows
> option:
> 
> # grub2-editenv list
> boot_success=1
> boot_indeterminate=0
> saved_entry=osprober-efi-E226-CF46
>

I think that's the problem, when GRUB_SAVEDEFAULT="true" in /etc/default/grub, grub2-mkconfig sets a save_default=true in /boot/grub2/grubenv. That variable is used by the blscfg module to know if the linux boot entries have to be set as the default when chosen.

Can you please try running grub2-mkconfig and not clear your grubenv after that? Otherwise that variable won't be set. You can also fix it by doing grub2-editenv - set save_default=true

I can't make it work no matter what I do.
I've run every permutation of grub2-mkconfig and grub2-editenv and it just won't work.
Currently I have the opposite problem. When I boot into Windows, it doesn't remember and it defaults back to Linux the next time.

Here's /etc/default/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="rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb quiet"
#GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

Here's /boot/grub2/grubenv:

# GRUB Environment Block
kernelopts=root=/dev/mapper/fedora_localhost--live-root ro rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb quiet 
save_default=true
boot_success=0
boot_indeterminate=0
saved_entry=426b2d6b4ed64df2bded8a8967196ecd-5.6.16-300.fc32.x86_64
###...

(In reply to Garrett Mitchener from comment #45)
> I can't make it work no matter what I do.
> I've run every permutation of grub2-mkconfig and grub2-editenv and it just
> won't work.
> Currently I have the opposite problem. When I boot into Windows, it doesn't
> remember and it defaults back to Linux the next time.
> 
> Here's /etc/default/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="rd.driver.blacklist=nouveau modprobe.blacklist=nouveau
> nvidia-drm.modeset=1 resume=/dev/mapper/fedora_localhost--live-swap
> rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap
> rhgb quiet"
> #GRUB_DISABLE_RECOVERY="true"
> GRUB_ENABLE_BLSCFG=true
> 

You are missing GRUB_SAVEDEFAULT=true in your /etc/default/grub.

Add that and re-generate your grub.cfg and it should work.

Okay, I think I've got everything set in all the right places and it seems to finally be working. Thanks!