Hi, On 10/5/22 20:56, Christopher Klooz wrote: > > On 05/10/2022 20:28, Hans de Goede wrote: >> Hi, >> >> On 10/5/22 19:59, Christopher Klooz wrote: >>> On 05/10/2022 18:39, Christopher Klooz wrote: >>>> On 05/10/2022 17:33, Chris Murphy wrote: >>>>> On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote: >>>>> >>>>>> However, on ask.fp, a user mentioned that the grub menu is no longer >>>>>> enabled by default on single boot systems so that changing the kernel is >>>>>> no longer easily possible, and put forward >>>>>> https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for >>>>>> this argument. Yet, the article indicates that the argument is not fully >>>>>> correct and even with single boot installations, SHIFT can be used to >>>>>> get into the grub menu. >>>>> I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found, because it's reserved by UEFI firmware for one of its menus. And SHIFT has never worked. Maybe Esc or TAB? >> Holding left shift is the easiest method, but with firmware being >> firmware does not work on all systems. >> >> What does always work is ESC or F8, Fedora's grub supports both to >> show the menu. On some systems one of those key get intercepted by >> the firmware which is why there are 2 choices. >> >>>>> Given this inconsistency, I have a mixed opinion of the hidden GRUB menu. >>>>> >>>>> >>>> Me, too. Especially as it makes support more problematic for unexperiened users. It is easy to say that people should push another kernel when they see the grub menu. They see text, and I can tell them which text to choose. But with unexperiened users, telling when to push tab/esc/shift/F8 can already need to start an elaboration of what "boot" means and when this happens and so on. Such elaborations are already annoying for them (and for the supporters). >> The menu automatically unhides after a failed boot. Just blindly >> doing ctrl + alt + f4 followed by ctrl + alt + delete; or just >> power-cycling the machine counts as a failed boot. > Many problems that can occur do not cause a failed boot. This starts with the current issue in 5.19.12. Assuming the current issue causes users to not be able to login, it does count as a failed boot. On Fedora workstation a successful boot is the user loging in in gdm and the user session then lasting at least 2 minutes. Or the user shuttingdown/rebooting the machine from the GNOME system menu. Anything else counts as a failure. > Another widespread issue is that users have problems with a piece of hardware (e.g., bluetooth controller), or with modules causing unintended behavior with one kernel (freeze, slow, something like wifi or bluetooth does not work, other acpi issues, and so on). All that does not necessarily cause failed boots, but is widespread among our "user base" at ask.fp especially because Fedora is used on much different hardware, and some needs additionally external modules. If a user can interact with gdm / GNOME then they can keep left-alt pressed while on the confirm you want to reboot screen, this will visible change "Restart" into "Boot Options" and clicking "Boot Options" (while keeping left-lat pressed) will then cause the grub menu to show for 60 seconds the next boot. Also power-cycling / ctrl+alt+del rebooting from a text virtual console without logging in will show the menu on the next boot. I have put a lot of effort in making it easy for users to still get the menu if necessary. To me it seems the biggest problem is users not being aware of the various options to get the menu when they need it. Also I want to point out that the reason which started this thread, the phoronix post about LCD panels possibly getting damages is mostly scare-mongering. Yes theoretically LCD panels might get damaged but there have been 0 reports about this and this is already fixed now. In my experience making policy changes as a sort of shooting from the hip reaction to a specific incident is usually a bad idea. For an extreme example of this see how 9-11 has got us all sort of draconian surveillance laws all over the world. Regards, Hans _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
