On Mon, 18 Jun 2018, Lennart Poettering wrote: > On Do, 14.06.18 14:20, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) 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@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/QGECPUQBDZFIWDTYZRBJGIBHOVAIHALZ/
