Re: Laptop powerdown when early boot incl. bootloader phase stuck (Was: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt)
On Friday, August 23, 2019 12:34:50 PM MST Chris Murphy wrote: > GRUB verifies the signature of the kernel before it is booted, in the > Secure Boot enabled case. Correct, but that's one architecture, but failing to load an image is a fatal error. > a. Press any key before the timeout and it won't shutdown > b. Power back on, and don't walk away, so you can press any key before > the timeout, and it won't shut down There is currently no functionality in GRUB for a timeout upon a fatal error. If there was, how exactly would that be useful? You'd get back to your system, and it's just shut down for some random reason. You power it back on, expecting to get back to work, and suddenly there's the same error that could have just been waiting for you right there on the screen. Regardless, if implemented, that works when it's your only system. What do you do when you're a sysadmin managing a few hundred workstations? Just wait for users to complain about individual systems? > The only way you're going to troubleshoot bootloader problems is > having the equivalent of physical access. Right, that or IPMI or KVM, but I don't know what that would have to do with implementing a timeout in GRUB. -- John M. Harris, Jr. Splentity https://splentity.com/ ___ 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
Re: Laptop powerdown when early boot incl. bootloader phase stuck (Was: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt)
On Fri, Aug 23, 2019 at 12:59 PM John Harris wrote: > > 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. GRUB verifies the signature of the kernel before it is booted, in the Secure Boot enabled case. > > 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? a. Press any key before the timeout and it won't shutdown b. Power back on, and don't walk away, so you can press any key before the timeout, and it won't shut down The only way you're going to troubleshoot bootloader problems is having the equivalent of physical access. -- 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
Re: Laptop powerdown when early boot incl. bootloader phase stuck (Was: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt)
On Friday, August 23, 2019 11:06:18 AM MST Chris Murphy wrote: > On Fri, Aug 23, 2019 at 5:48 AM Jan Pokorný 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. Splentity https://splentity.com/ ___ 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
Re: Laptop powerdown when early boot incl. bootloader phase stuck (Was: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt)
On Fri, Aug 23, 2019 at 5:48 AM Jan Pokorný 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
Re: Laptop powerdown when early boot incl. bootloader phase stuck (Was: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt)
On Friday, August 23, 2019 4:46:53 AM MST Jan Pokorný wrote: > On 20/08/19 20:59 -0600, Chris Murphy wrote: > > There is no good reason for the current behavior, in particular on a > > laptop. And it's fail danger, not fail safe. The very simple work > > around for the computer shutting off in 3 minutes of inactivity and > > you don't like that? Power it back on and enter your passphrase. > > Shockingly easy and obvious. Unless of course you're stuck somewhere > > and in fact want to use your laptop as a heating pad. > > Just that the particular corner case is not perceived in isolation, > there are other early-boot-stuck situations that would make sense > to deal with in the same fashion even if the sources are completely > different (predictability is more important from user's POV, IMHO). > > 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. > That's directly comparable to the LUKS prompt without any attention > for a prolonged time. > > With grub2, situation is actually worse, since without having any > means to control CPU throttling (which is already present by the > time one is to enter LUKS password), laptop will indeed become > said "heating pad" after a bit (one could for instance enter the > grub prompt if it's deemed a feature for some). To clarify on this a bit, GRUB will only stat "in the selection menu without any timeout for whatever reason" if it is either not configured to automatically select an entry after a timeout, or a key is pressed before the timeout, meaning GRUB expects you to choose a different boot option. As for "stuck in 'press a key to continue'", if it didn't do this, you would have no way of knowing what the error is to recover your system. -- John M. Harris, Jr. Splentity https://splentity.com/ ___ 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
