This user is planning on not trying Linux again, because they had a broken Kernel, and the boot menu where you can select the older one, is hidden by default!
It makes troubleshooting (or avoiding troubleshooting) on the Forum a huge pain, to not know what key to press, to show GRUB.
Again, I want to say that hidden grub impaires usability lot. Fedora is semi-rolling, and the kernels are not battle tested like on RHEL.
I think it is not appropriate to hide these critical troubleshooting tools. Fedora is a testing ground, even though it is not marketed as such. I think we need as many tools as possible to make the experience stable anyways (like Atomic Desktops).
What do you think?
I would be really happy about a change, to have a themed not hidden GRUB. The “hide grub” option can be documented for everyone wanting that.
But troubleshooting should never be hidden by default, I think.
With a theme (which should be placed in /boot somewhere to avoid LUKS issues) it would also look nice.
I have to disagree. None of the OSes filling the same general role and purpose as Fedora Workstation show the bootloader’s menu by default:
Windows 7/10/11 doesn’t show the bootloader by default (Available if the last boot failed or ended abruptly).
MacOS doesn’t show the bootloader by default.
Ubuntu and OpenSUSE do not show the bootloader by default.
I really don’t see a good reason for Fedora to deviate from the standard. Instead of showing an annoying menu which delays the boot process and makes the machine feel more sluggish, GRUB should be improved instead so its menu can be invoked more easily.
For example, we could make any keypress bring up the menu, or give users a bit more time to press the button. We should also discard inputs sent shortly after the menu is entered, so users don’t accidentally end up in the GRUB command prompt or pick the wrong boot option.
The boot process is, quite literally, the user’s first impression to the OS. It should look as fast and seamless as possible.
Personally, I am a systemd-boot apologist. The way it handles showing the boot menu is by checking if any key is being held when it starts.
I have to disagree with these 2 points, as those systems tend to not have as frequent and potentially volatile updates to a critical component such as the kernel. Whereas on Linux, this is far more frequent, with changes more critical to the boot process with users “expected to know” what/how to do things.
More so, with the removal of the root account password, some users experience not being able to troubleshoot as a root account is required in Emergency Mode. It’s compounding issues that the layman rarely experience on Windows or Mac software systems.
systemd-boot user here. I will go as far as to say “It should be the default”. Although I know it “can’t be for reasons”
IIRC, GRUB already has a mechanism in place that forces the boot menu to appear if the last boot attempt failed. These cases should be covered by said mechanism. The solution is to fix/improve that mechanism, not make the boot user experience worse and slower.
While it’s true that Fedora’s fast-moving nature and Workstation not being a supported OS in the majority of hardware its used in makes Kernel regressions more likely, it’s still pretty rare overall - certainly not common enough to use a hammer like this.
That’s an orthogonal issue to the bootloader question placed here. Even if we were to make it always show up, Fedora would still not have any kind of recovery image. (The “recovery kernel” is rarely useful, in practice.)
All that the GRUB boot menu does is give you a list of kernels to boot - it’s useless and unhelpful in situations where anything else breaks. It’s only useful if the user messes with bootloader configuration and breaks it, or if a new kernel they installed is broken on their hardware.
Fixing this would require Fedora to store a small recovery environment (akin to a LiveCD) in a separate partition, which I’m also apologetic towards.
Definitely. Avoiding this can of worms which I really want to opendon’t want to open.
I suspect that grub thinks the boot succeeded but during systemd boot it gets stuck. In these cases booting the previous kernel is often the way back to a working system.
I don’t know how a successful boot is marked, so I am unsure about which user issues keep the menu hidden.
There is something perverse about expecting a system to “judge” itself as to whether it is working correctly. I mean, from the system’s perspective, the boot menu is hidden, therefore the boot was successful.
From what I can tell:
It’s marked by a user timer and service. grub-boot-success.timer grub-boot-success.service
which runs: /usr/sbin/grub2-set-bootflag boot_success
and is checked in /boot/grub2/grub.cfg
You can manually show it on a reboot by doing sudo grub2-set-bootflag menu_show_once
You should also be able to hold the shift key during boot or press F8 during boot to show it.
It might be nice to have something accessible via menu to toggle it for troubleshooting.
It might also be nice to be able to temporarily clear rhgb quiet from the boot parameters as well.
This could be achieved by always doubling the latest kernel entry in GRUB, but with the adjusted parameters, and calling it something like Kernel 1.2.3…-fc40 Verbose mode.
You can make duplicate entries using grubby but you have to hand modify the /boot/loader/entry to remove the arguments since update kernel would update them both. grubby --add-kernel="/boot/vmlinuz-6.9.8-200.fc40.x86_64" --title="no quiet kernel" --initrd="/boot/initramfs-6.9.8-200.fc40.x86_64.img" --copy-default
`
You can use sudo grub2-reboot <index #> to boot the entry.
On Gnome, after hitting restart you can hold the alt key and boot options will come up. Select that and it will also show the grub menu.
Maybe the change should be to set menu_show_once when there is a kernel or mesa or … insert packages that normally break things here …
It is also true that many people who decide to install linux, tend to tinker and fiddle with the system. They should be well disposed to understand and discover how things work. Pressing a key during boot doesn’t need a degree.
How many Mac or Windows users do you think know what key to press during the boot process in order to attempt a recovery?
So, for ordinary people[1] that need a system to do things, it is far better a smooth boot process hiding all these hacker style messages and menus.
Almost none of them, but then Microsoft and Apple have a lot more resources to test their software before release. However when they do break there are guides, with picture of what to do for the people who are not technical.
The machine in question would boot the kernel but not to the point of creating any logs or having any meaningful information displayed with or without rhgb quiet.
After failing to boot the grub menu was displayed and I was able to boot to a working kernel. After this, used grubby to set the default kernel back to a working version so at least it would boot.
Maybe we should start with a howto troubleshoot boot issues and see where that goes.
x