On Mon, 18 Jun 2018, Lennart Poettering wrote:
On Do, 14.06.18 14:20, Chris Murphy (lists(a)colorremedies.com) wrote:
> The cited BLS spec is the original one, [1]
... later: L.P.:
[reduce] the size of the spec if possible, and drop as many
bits of it as we can, i.e. the stuff noone implements
anyway.
> The cited BLS spec requires $BOOT be VFAT, are we doing that?
Will cgroup and SElinux protections work in VFAT ?
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
I see a lot of need in [1] for re-partitioning and optionally
adding a /boot partition where none was specified, to make
this work
The move toward containers includes getting away from more
than a single partition (and so, a separate /boot partition,
as mostly irrelavant). Getting rid of a separate /boot
partition is a win, as it removes the need for a separate
mountpoint in /etc/fstab for a '/boot/'. partition, and all
the gyrations as to partitioning in [1]
N.B.: This is a 'Good Thing' as one does not get 'out of sync
with each other between 'root of filesystem', and /boot/ when
they are all in a single filesystem
So, in systemd we ship a generator that automatically establishes
automount points for the ESP. It will preferably use /efi as mount
point if it exists and is empty. If it doesn't exist or isn't
empty it will use /boot — if that exists or is empty. If neither exist
or are empty it won't do anything
I think this last is a negative:
... it won't do anything
and I submit that the proper course, when no /boot partition
is seen, is to properly mount the root of filesystem, and do
a:
mkdir /boot
and then continue on
To wrestle with all the failure modes, I see a lot of
fall-through logic, and a lot more complexity, including
re-partitioning by the boot loader on a device it may not have
RW rights at the partition table level -- yikes, as to an
added point of faiure -- outlined in the initial proposa [1]l,
but not implied in Matthew Garrett's [2]
But for the fact that that kernel updates do not 'just apply'
with the current grubby / dracut regime, the approach of a
/boot/ directory (but not separate partition) works in
production just fine and has for over a decade [3]
I suspect that moving to such as an option, and adding a
systemd umount RW / remount RO of 'root of filesystem' on the
way to a shutdown, would ameriorate if not totally remedy [4]
and [5] as well. Just the remount RO by systemd will cause
the needed 'sync' actions on the way down would solve: [6] and
its Fedora twin: [7]
If a '/boot/' partition is absent, simply creating a /boot/
directory at the root of the file system does away with the
need for many of the gyrations of [1].
-- Russ herrold
[1]
https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
[2]
https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/
[3]
https://bugzilla.redhat.com/show_bug.cgi?id=1498169
[4]
https://bugzilla.redhat.com/show_bug.cgi?id=1533620
[5]
https://bugzilla.redhat.com/show_bug.cgi?id=1569970
[6]
https://bugzilla.redhat.com/show_bug.cgi?id=1464611
[7]
https://bugzilla.redhat.com/show_bug.cgi?id=1466036