Re: F29 System Wide Change: Make BootLoaderSpec the default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mo, 18.06.18 10:30, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote:

> >> The cited BLS spec requires $BOOT be VFAT, are we doing that?
> >
> > Why would we? I mean the idea is that $BOOT can be shared among
> > multiple OSes installed. Which means one really should settle on a
> > format anyone can read. And VFAT certainly qualifies as that, most
> > other file systems do not.
> 
> Do you mean "why wouldn't we?" Flipping over everyone's /boot to
> become the ESP on VFAT is a substantial change so I'm asking the
> question, yet again. This was asked a long time ago with the original
> conversations on this list about BootLoaderSpec, and those questions
> and answers are addressed in Matthew Garrett's derivative of the
> spec.

The boot loader spec suggests that $BOOT and the ESP are the same
thing, and I am very sure this is the best and simplest approach for
all images that have no explicit reason to depart from that. However,
the spec does not actually require $BOOT to be the same as the
ESP. The freedom to make $BOOT != ESP was added as a compromise,
because some folks were adamant that resizing the ESP on multi-boot
systems should not be done (i personally don't think it's as big a
prob as people claim though...).

Today, systemd has this generator that will automatically find the ESP
for you and mount it to /efi or /boot. The idea behind that is that
installers can choose whether they want to merge $BOOT and the ESP or
not:

1. If they are merged, then the ESP (and thus also $BOOT) is mounted
   to /boot, automatically by the generator. No other preparation is
   needed, and /efi does not exist. (Distros could even make /efi a
   symlink → /boot, but I personally wouldn't bother).

2. If they are not merged, then the ESP is mounted to /efi,
   automatically by the generator. And /boot would be mounted as $BOOT
   via an /etc/fstab entry added by the installer.

And as mentioned, I'd generally recommend everybody to go for option
#1 because it is a lot simpler, and EFI has trivial access to all
kernels and such. The boot loader can start the EFI shell and its
trivial to explore the contents and everything and manually boot any
kernel you like. This approach also means that no /etc/fstab entry is
needed, and thus things are a lot more self-sufficient and robust.

It would be my assumption that all OS images generated in full by some
image builder would go for option #1, and option #2 would only be used
when a traditional installer such as anaconda is used that is supposed
to add a Fedora installation to a system that is already set up
otherwise, i.e. already has an EFI partition in place that is
considered too small. i.e. option #2 is the multi-boot-with-windows
usecase, while option #1 is for pretty much everything else.

> > 1) The chance that the ESP remains in a clean state is maximized, as
> >    the file system is unmounted whenever possible, and only mounted
> >    for a short time window around actual disk accesses. This is the
> >    behaviour you really want for something as fragile as the ESP.
> >
> > 2) It's compatible with current behaviour, as the path is always
> >    accessible under a fixed name, requiring no explicit mounting.
> >
> > 3) There's no need to configure any lines for the ESP in /etc/fstab
> >    anymore. Instead the system will discover the ESP automatically and
> >    make it available. This means the installer can be simpler, and
> >    things are generally more robust as /efi (or /boot) will follow
> >    what is in place, instead of require a separate layer of
> >    configuration that has a good chance of getting out of sync.
> 
> I've got no complaints with this although as mentioned in the other
> thread "f29 bootloader changes / raid1 installs + efi" this generator
> lacks the intelligence needed to support multiple ESPs for any RAID
> use case, e.g. md or LVM or Btrfs RAID1.

Well, if you really want to cover this, then using the automount stuff
actually allows you to solve this much nicer than traditional setups:
write a service (possibly just a script around dd with some locking
might suffice) that is pulled in by the .mount unit that the
.automount unit is backed by, and is ordered before the .mount
unit. This then means its ExecStart= and ExecStop= line would run
before and after the mount is around. In ExecStop= you could then dd
the mounted file system onto the other copies. And we'd do though
automatically after each series of accesses.

> > I'd love to see Fedora adopt this generator. Primarily this would mean
> > some chnages to anaconda I guess. It would make things simpler and
> > more robust. That said, the generator only cares about the ESP, not
> > for cases where $BOOT is backed by any other partition.
> 
> Ok so you're saying if $BOOT is type 0xEA, or type
> bc13c2ff-59e6-4262-a352-b275fd6f7172, the generator will not automount
> it at /boot ?

systemd will do the discovery and automount unit generation only for
the ESP, and it's very defensive, i.e. it will never over-mount
neither /boot or /efi if there's anything in there, or if there's
already an explicit line for in /etc/fstab and such.

If you want to separate $BOOT from the ESP, then let the generator
handle the ESP for you under /esp, and mount $BOOT yourself with an
fstab entry.

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
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/message/A3KO4LXBJC2SLHHLVXAV7PLXZXG4PWKZ/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux