I'd like to suggest that the bootloader_menu_autohide be false (default) for silverblue for now. There are too many things related to partitioning, bootloader, assembly and startup and this polish feature I'm finding to be a hindrance in testing.
I find the feature enabled in Workstation here:
But I'm not finding a silverblue specific install class, so I'm guessing silverblue is using the workstation one because my recent silverblue 29 installs definitely hide the grub menu.
You didn't spell out any of the "things related to...", which does not really help resolving this.
I'd prefer to keep it hidden.
a) creation of grub.cfg is completely different on rpm-ostree based systems; if the user decides to poke around and add customer boot params and regenerate the grub.cfg using grub2-mkconfig, the system will be unbootable; this has been an ongoing source of confusion and lack of sane well documented work arounds for a long time.
b) bootloaderscript by default is a major change on the way that will change how we boot, there will inevitably be regressions (I've run into a couple) that are solved only by hand editing the boot entries
c) many if not the vast majority, of possible custom partitioning layouts result in an unbootable system; either due to failure at installation time, or failure in assembly during startup.
In theory, in all of these cases, the lack of boot success means the next boot should mean the grub menu is visible. And possibly examples of each of these problems needs their own silverblue issue rather than as bug reports. So it isn't any sort of deal killer to have autohide enabled, I just find it's more of a burden and premature while so many things are not stable yet.
If you do any of those things (add custom boot params, run grub2-mkconfig, use custom partitioning), you are expected to either know enough to make the grub menu visible, or be stubborn enough to reboot one more time and have the boot failure logic kick in.
I'm suggesting disabling it temporarily to better facilitate troubleshooting, and getting problems fixed sooner than later. Essentially anything offered in the installer that doesn't work is a blocker bug for release blocking images. I'm not nearly as concerned about testing autohide and boot fail fallback, and in the near term that's a testing hurdle.
I'm closing this issue - if the problem persists, please open a bug report in https://github.com/fedora-silverblue/issue-tracker/issues.
Metadata Update from @tpopela:
- Issue status updated to: Closed (was: Open)
to comment on this ticket.