On Friday, August 23, 2019 11:06:18 AM MST Chris Murphy wrote: > On Fri, Aug 23, 2019 at 5:48 AM Jan Pokorný <jpokorny@xxxxxxxxxx> wrote: > > > > One such other situation is having the bootloader (grub2) failed and > > hence be stuck in 'press a key to continue' or just staying in the > > selection menu without any timeout ticking for whatever reason. > > > There is signature verification of all the bootloader binaries, and > the kernel, in the UEFI Secure Boot case. I'm not sure what kind of > signature checking could be enabled in the case of UEFI Secure Boot > disable and BIOS and other firmware types. First, there'd need to be > some way to identify an error, then what can be done (try another > kernel, OK what if that fails?) to mitigate it. > > Since Fedora 30, the grub.cfg is no longer modified by grubby, it's a > static configuration file. So at least in the normal case, it's > created correctly from the outset and other than bit rot it should > always be present and correct forever. What if any of that changes? > I'm not sure what the fallback behavior is, it's possibly worth > exploring. The Fedora GRUB BLS module does have some sanity testing of > the BLS snippet in it, but I'm not sure how robust it is and if > there's a fallback other than trying another menu entry, which means > trying another kernel. At the point which it's exhausted all menu > entries and kernels, then what? Does GRUB in the pre-boot environment > on all archs have the capacity to power off the system? I'm not sure. > It's an interesting question. GRUB does not have the ability to halt the system on all architectures, but it does on most. That said, there are some things to consider: If GRUB was able to load the kernel and initrd/initramfs image, even if it's corrupt, it will execute that. At this point, GRUB is no longer running. Do we really want to have no indication that something went wrong, and just poweroff the system, upon a failed boot? How is that a good idea for any system, servers, workstations or laptops? -- John M. Harris, Jr. <johnmh@xxxxxxxxxxxxx> Splentity https://splentity.com/ _______________________________________________ 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
