On Mon, 18 Jun 2018, Lennart Poettering wrote:
> On Do, 14.06.18 14:20, Chris Murphy (li...@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
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org/message/QGECPUQBDZFIWDTYZRBJGIBHOVAIHALZ/
