On Sat, Jul 4, 2020 at 10:19 AM Lennart Poettering <mzerqung(a)0pointer.de> wrote:
If it way my decision I'd propose the following as the path to
the
future:
1. Unify/standardize on the boot loader spec, not the boot loader
2. Let's use UEFI as model and make MBR boots more alike UEFI then the
other way round (right now, UEFI boots in grub are considered a
special case, and booting on UEFI is attempted to be as close as
possible to MBR). i.e this is a race-to-the-bottom
vs. race-to-the-top issue: make the stuff that doesn't work like
today's industry standard work like it, and don't make today's hw
work like the industry standard of yesteryear.
Specifically this means:
a. Teach grub proper boot loader spec support (and maybe boot loader
interface support too,
i.e.
https://systemd.io/BOOT_LOADER_SPECIFICATION +
https://systemd.io/BOOT_LOADER_INTERFACE)
b. Prepare a static no-module build of Grub that reimplements roughly
how booting on EFI works: i.e. support only VFAT file systems, then
search for suitable partitions (ESP/XBOOTLDR), and retrieve boot
loader spec entries from them, and populate the menu by it, and
that's it. Do this the same way on all archs we support, regardless
if MBR or ARM or EFI boot protocols.
As I understand a good chunk of a/b already exists.
I agree with all of this. But multiple projects (distros but also
project within even Fedora) boot differently and put pressure on
bootloader folks. GRUB is simultaneously unwieldy and indispensable.
The cost of abandoning it, or reorganizing either the upstream
approach or Fedora's approach to it, is incredible to imagine let
alone implement. And thus far upstream GRUB seems intractable on
Bootloaderspec, or giving sufficient feedback on modifications to make
it viable. It's a sand trap.
Why do the security folks want POSIX and SELinux labels on the
contents of /boot? I've never really gotten a straight answer on this,
but I know it's considered important and a sticking point for why some
folks do not want the kernel and initramfs and bootloader
configuration files on FAT. And can it be mitigated some other way?
Maybe not persistently mounting /boot and /boot/efi or mounting them
on-demand elsewhere only when they need to be modified?
There are other use cases folks are interested in. Here's one:
https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Boot_on_Btrfs
That aims to make it possible to support a snapshot/rollback regime.
There needs to be a way to pair the states of /boot and / so that the
kernel we're using to boot a rollback, has modules available on the
rolledback /usr. That does not need to be done with Btrfs, even though
it's probably easier, since we have examples of this already from
(open)SUSE that we know work very reliably. It's a solved problem that
is also well understood. The unsolved component to that though is how
to do it with Bootloaderspec. Is it possible at the same time we
figure out a way to not require /boot to be Btrfs? I'm open to the
idea even though I'm not sure what it looks like. Hence why this is an
option in the proposal, not part of the base proposal.
Everyone wants out of the sand trap, but we're also more comfortable
sticking with the problems we know rather than jumping into problems
we don't know. And then also RH/Fedora bootloader folks are busy
enough as it is holding up the fort, with few cycles to look at
planning and implementing a new design.
--
Chris Murphy