I have a dual boot Windows 10/Fedora 38 system. Recently I thought I saw something related to grub amongst the system updates. Now whenever my system is booting up, I don’t see the grub screen with the entries for selecting Windows or one of the Linux kernels, it just seems to bypass the screen altogether and always goes into Windows. If however, I press Shift during the bootup, I do get the grub screen.
Here is my file at /etc/default/grub:
As you can see the first 2 lines are there to give me the menu and I changed the timeout value to 10. Also, default is 0, which is Windows (for the sake of other users of the computer)
From the file properties, it looks as though the grub file was last modified Sept 13. I was trying to read the grub documentation but I can’t seem to get to the gnu website, it seems down at the moment. is DISABLE_SUBMENU=true the culprit?
Yes, I want the menu visible. That way, I can scroll down to choose whichever kernel I want to use, but for the non-Linux users of the computer, they just let it time out and it boots into Windows for them. The recent issue is that I wasn’t seeing the menu at all, so I was having to press Shift during boot (which I find annoying).
In any case, I figured it out. The GRUB_DISABLE_SUBMENU set to true doesn’t doesn’t fix it, what it does is put all the available kernels into its own collapsible line. But in updating the grub configuration, I realized other changes had been made (presumably because of the update to the grub package), and what I saw in grub-customizer was different that I had last left it. There was a ‘Fedora’ entry, in addition to the long-named kernel entries and the Windows entry.
In any case, after rearranging to have Windows at the top, and the kernels just underneath it, and updating grub, all is at it was again. I just have to stay on top of this not just when a new kernel is provided (which always ends up at the top of the grub configuration), but I should check things whenever anything to do with grub is updated.
Apparently what happened was that since you had used grub-customizer, the update to grub changed that config. This seems that whatever configs grub-customizer does is written over something that grub itself does so using that particular tool may result in similar issues whenever grub is updated.
I never use grub-customizer so that does not happen to me. Instead, if I wanted windows to be the default boot kernel I would use grub itself to set the default.
Please check the output of sudo grub2-editenv - list and see what the setting of menu-auto-hide may be. If that is set and shows as menu-auto-hide=1 then the menu is normally hidden. Potentially that is why the grub menu disappeared. The grub update may have changed the grubenv settings back to default.
Note also that since installing a new kernel atomatically places the new kernel in index position 0, which is why you have to change it everytime there is a kernel update to keep windows as the default, you could use the title of the windows entry as the default and avoid that issue. This is a snippet from the info grub2-mkconfig page (section 6) about that.
‘GRUB_DEFAULT’
The default menu entry. This may be a number, in which case it
identifies the Nth entry in the generated menu counted from zero,
or the title of a menu entry, or the special string ‘saved’. Using
the id may be useful if you want to set a menu entry as the default
even though there may be a variable number of entries before it.
For example, if you have:
menuentry 'Example GNU/Linux distribution' --class gnu-linux --id example-gnu-linux {
...
}
then you can make this the default using:
GRUB_DEFAULT=example-gnu-linux
If it shows menu-auto-hide=1 then that can be changed so the menu never hides with the command sudo grub2-editenv - unset menu-auto-hide then verify that setting is removed with the list command given before.
Thanks to you both.
Ok so I unset menu-auto-hide (ironically, when you run the command, you type it as menu_auto_hide, but when you use the list command to verify the status, if it is set it shows as menu-auto-hide). Note the subtle difference
One last thing regarding this: In setting the default-os by id rather than by entry number, I’m not seeing “–id” as per the example, here is what I have:
menuentry “Windows Boot Manager (on /dev/sdc1)” --class windows --class os $menuentry_id_option ‘osprober-efi-64EB-DFA9’ {
But 'menuentry_id_option is a bit of a hint, so I set GRUB_DEFAULT to osprober-efi-64EB-DFA9. I’ll leave it like that and see what happens at the next kernel update (which is never far off for Fedora).
Theoretically, when dual booting the grub menu is always supposed to be visible during boot. It certainly is on my laptop which is the only dual boot system I currently have.
This is the unaltered grubenv content on that machine which has always displayed the grub menu from the first time I booted after installing fedora.
# grub2-editenv - list
saved_entry=4721ae52e35645e2b20bd190dd29ced1-6.4.14-200.fc38.x86_64
menu_auto_hide=1
boot_success=1
boot_indeterminate=0
Just wanted to put a bit more info in the thread, since there was a kernel update to 6.5.5.
First off, my hunch about using GRUB_DEFAULT=“osprober-efi-64EB-DFA9” worked. That is the name of the entry that will boot Windows 10 by default, regardless of the order of the entries. The new 6.5.5 kernel is now at the top of the list, but Windows remained the default. (which is what I want)
However, the grub menu didn’t get updated on its own after the new kernel was installed. (To be clear, this has always been the case for me AFAIK.)
I still have to run the following (which I always had to do):
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Should this command have run on its own during update?
Searching on this issue, I found this thread:
I see that in my /etc/default/grub, I have GRUB_ENABLE_BLSCFG=“false”, so I’m wondering if this could be the cause
That command has not been valid since about the release of fedora 34.
The correct command is sudo grub2-mkconfig -o /boot/grub2/grub.cfg
What your command does is overwrite what should be a pointer file that redirects grub to the proper grub.cfg file, and until the file under /boot/efi is repaired it will always require a manual update of the grub.cfg file since the ‘pointer’ file is normally never altered once properly installed.
The fix is really simple, and once completed then the automatic grub updates with new kernels should function properly.
Thanks for hanging in there with me. I guess I fell victim to using outdated info. I did think it was weird that there seemed to be grub and grub2, but I didn’t piece everything together.
You cut through the fog and resolved everything, thank you so much.
(FYI I toggled GRUB_ENABLE_BLSCFG to true and the fedora entries disappeared, so I toggled it back to false)
GRUB_ENABLE_BLSCFG set to false is no longer a supported configuration, meaning that the the configuration is not automatically updated when you upgrade to a new kernel. About 10 releases ago, every configuration was automatically converted to GRUB_DISABLE_OS_PROBER=true and the bls files in /boot/loader/entries created.
You said that, but on my F39 system (converted from rawhide to F39 when the branch occurred and updated regularly) I see this and it still has the GRUB_ENABLE_BLSCFG=true line in it. It seems that @gaston should be able to convert that line to match mine and still have everything work properly – especially since the boot menu seems created by blscfg.
Ok so I commented out the GRUB_ENABLE_BLSCFG line and added the GRUB_DISABLE_OS_PROBER=true line, though I had to change it to false in order to see my Windows entry.
Is there anything that has been deprecated, but is somehow still in the file?
The only thing I can think of is that I was using grub-customizer, maybe that added the lines involving deprecated features.
You only have 3 lines in there that I do not (by default) GRUB_TIMEOUT_STYLE=“menu” is not normally used since the default for systems that only boot linux is “hidden” and the default for dual boot systems with a different OS is “menu” This is controlled by the menu-auto-hide setting in grubenv. GRUB_DISABLE_OS_PROBER=“false” is the same as not having that line at all – the default is ‘false’. Normally os-prober is used when grub is configured to locate and add other OSes to the grub menu – which explains why windows was not shown when you set it to true. GRUB_SAVEDEFAULT=“false” is also showing the default. Switching it to ‘true’ would mean that the system always boots the last used kernel/os as the default and it would change the default every time a new kernel was manually selected to boot.
Note that none of those lines are in what I posted.
Note that your line GRUB_DISTRIBUTOR=“$(sed ‘s, release .*$,g’ /etc/system-release)”
slightly differs from mine below, though I have no idea if that is an issue. GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
That is what is supposed to be, so you are fine. However some tutorials have sometimes recommended to switch to GRUB_ENABLE_BLSCFG=false, which the Original Poster might have done.
There is a command grub2-switch-to-blscfg that is supposed to switch to BLS, and it might still work.
Edit: I have done some testing, and I found out that the bls files are always created regardless of the value of GRUB_ENABLE_BLSCFG. This means, that when switching to GRUB_ENABLE_BLSCFG=true and rebuilding the grub.cfg, the kernel entries should be there, as seen by running grubby --list ALL. The grub-customizer can’t be trusted here.
