On Fri, Aug 23, 2019 at 5:48 AM Jan Pokorný <jpoko...@redhat.com> 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. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
