On Sun, May 24, 2020 at 5:07 PM Paul Dufresne via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Well... I will try to repeat more clearly my claim: > > If Fedora want to pretend to implement the Boot Loader Specification, it must, on a new disk formatted in GPT, end up with an entry in fstab for an ESP partition mounted on /boot: > > "These directories are defined below the placeholder file system $BOOT. This placeholder file system shall be determined during installation time, and an fstab entry for it shall be created mounting it to /boot." In practice, Fedora's implementation is closer in some respects to this variant of the spec: https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ > "if the OS is installed on a disk with GPT disk label, and no ESP partition exists yet, a new suitably sized (let's say 500MB) ESP should be created and should be used as $BOOT" > > This is the rule you are supposed end up to follow for an empty GPT partition. > > And for now, the installer seems to make you define a specific /boot/efi that it make ESP. To follow BLS, it should be /boot that is the ESP partition... and I see no point to define an other /boot/efi partition to be mounted on /boot. Correct. Fedora went with a hybrid approach, rather than fully conforming to (either) spec. So in practice, it's an implementation without a spec. But that happens with web standards and various other specs too so it's not remarkable in that sense, even if it's confusing. > "$BOOT must be a VFAT (16 or 32) file system. Other file system types should not be used. Applications accessing $BOOT should hence not assume that fancier file system features such as symlinks, hardlinks, access control or case sensitivity are supported." Yeah it's difficult to cover all possible use cases this way, and the spec itself doesn't try to cover them. One of those that is still worse on UEFI, is the inability to support redundant boot with two drives. There needs to be some service or daemon that syncs the EFI System partitions on each drive, and software raid inadequately addresses the concerns, and creates new ones and for that md/mdadm upstream folks have consistently opposed such implementations and yet they exist and are as fragile as expected. Another problem is FAT isn't atomic so while it's possible to do rename atomically at the VFS level, it's not atomic on FAT so if you need such a guarantee when modifying the ESP, FAT leaves the door open (however small) to boot failure following a crash during an update of the ESP. I'm not sure how Windows solves this, or even if it does. Apple solves it by not not using the ESP for booting at all, they use an EFI file system driver so that the pre-boot environment can read APFS, and as that's a COW file system, all kernel and boot related updates happen atomically by design. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
