On Tue, Feb 12, 2019 at 2:18 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > In the short term it means any features depending on writing to grubenv from pre-boot GRUB (as opposed to Linux user space GRUB tools), can only be expected on UEFI (grubenv is always on FAT), or if on BIOS only with default (automatic) partitioning. That might be an acceptable limitation. The only feature I'm thinking of that depends on pre-boot GRUB writing to grubenv is resetting boot success to zero, which is part of the hide boot menu by default feature. If grubenv can be change from pre-boot environment, we can't correctly determine if boot has succeeded or failed. So what's the best fallback? Always show grub menu or always hide it? I think probably the former. If the grub.cfg code first reads grubenv, and sees boot_success=0 and therefore no need to write to grubenv to reset it back to 0, that's one first step. But then to make sure the systemd unit that marks boot successful by overwriting grubenv with boot_success=1, is there a way to disable (or not enable) that systemd unit if the user has chosen a custom installation in anaconda? -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
