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@michel-slm.name
chat via email:
https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2