Hi, On Tue, 2021-01-12 at 19:56 +0100, Hans de Goede wrote: > Hi, > > On 1/12/21 5:55 PM, Michel Alexandre Salim wrote: > > Hi, > > > > Thanks for the thorough reply, Hans! One question inline > > > > On Tue, 2021-01-05 at 12:31 +0100, Hans de Goede wrote: > > > Hi, > > > > > > On 12/30/20 11:52 PM, Neal Gompa wrote: > > > > > > > > The issues Michel is referring to do not apply to Fedora Server > > > > using > > > > Btrfs, because outside of Workstation, currently no variant of > > > > Fedora > > > > has cross-layer integration with the bootloader. > > > > > > I do not think that that is entirely true, well it depends on if > > > anaconda > > > also sets the menu_auto_hide=1 variable for other variants. The > > > grub > > > hidden > > > boot menu stuff: > > > https://fedoraproject.org/wiki/Changes/HiddenGrubMenu > > > https://hansdegoede.livejournal.com/19081.html > > > > > > Should mostly work, assuming they at least use a systemd user- > > > session. > > > > > > The boot menu being hidden or not depends on the boot_success > > > grubenv > > > variable, which gets set by a systemd-timer in the systemd-user > > > session > > > of non-system (aka normal) users if the user-session has lasted > > > at > > > least > > > 2 minutes. > > > > > > > `boot_success` needs to be cleared per boot though, right? So that > > if > > the user session timer doesn't set it back (so we assume the boot > > failed), the next boot shows the GRUB menu. > > > > Where does this happen? I'm under the impression this happened in > > the > > GRUB execution environment, which is problematic if that > > environment is > > on a filesystem GRUB can't write to. > > Correct this happens in the grub execution environment. > > > Apologies for seeing this late, it would be nice to get this > > information going into tomorrow's FESCo meeting since Javier's > > proposal > > has a -1 that is partly due to concern over breaking the hidden > > menu > > functionality -- https://pagure.io/fesco/issue/2543 > > So I've read Neal's comment there and what he describes really > is a special corner case, but yes it is possible for people to have > created the special setup he describes and yes in that case moving > grubenv to /boot will break the hidden-menu functionality. > > I'm not sure if this warrants a -1 to the proposal though, > I believe documenting this + some workaround for it should be > sufficient. > > But as mentioned in the fesco issue this has more to do with the > fact that storing the grubenv in a filesystem-file is a bad idea > in general. It's not necessarily bad unless the filesystem is journaled, right, since GRUB's filesystem drivers basically don't support this? (so basically it's only FAT-like filesystems and ext2 that's perfectly safe). > > As discussed in detail here: > https://pagure.io/fedora-workstation/issue/206 > we really should be moving away from that. As discussed there Suse > already has grub-patches to instead store the grubenv in an part of > the btrfs filesystem header which is reserved for bootloader use. > That's one of the option discussed, yes. One issue with doing it this way is we'll have to reimplement it for XFS and other future filesystems. > As @javierm says in the linked fedora-workstation issue, that is > also the long term plan for Fedora, but we really want to discuss > and develop a solution for this with/at grub-upstream so that we > don't end up with conflicting solutions between distributions > which stomp all over each-others data. > Agreed. But if we decide to use a separate partition with a properly supported filesystem, we might as well pick it now rather than make changes twice, right? Chris suggested using a BIOS Boot partition, but another possible option is to use XBOOTLDR from https://systemd.io/BOOT_LOADER_SPECIFICATION/ - which the BLS actually prefers over the ESP if found. (I made the mistake of assuming the change is up for discussion tomorrow, my bad. Looks like we have time to continue discussion here - or on the ticket) Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/michel@xxxxxxxxxxxxxxx chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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
