> On Jun 25, 2018, at 3:40 AM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > >> On Fr, 22.06.18 14:17, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: >> >> On Fri, Jun 22, 2018 at 12:57 PM, Lennart Poettering >> <mzerqung@xxxxxxxxxxx> wrote: >>> On Fr, 22.06.18 19:01, Javier Martinez Canillas (javier@xxxxxxxxxxxx) wrote: >>> >>>>> Whereas constantly changing the ESP, means we need some way to >>>>> establish a master and rsync to the extras. >>>> >>>> So the consensus seems to be to have the BLS fragments in >>>> $BOOT/loader/entries even on EFI, where $BOOT is the boot partition >>>> mounted on /boot. That will give us the following advantages as >>>> mentioned in this thread: >>> >>> Uh, as one of the authors of the spec, I am not convinced using >>> arbitrary non-FAT file systems for $BOOT. In fact the spec currently >>> says it has to be VFAT. I wouldn't call that "consensus". >> >> Lennart, I sympathize, but face it. There is a single implementation >> of kernels and initramfs on the ESP and that's systemd-boot. Everyone >> else wants to get as far away from vfat as fast as possible. For a > > I am not sure why you are making this about systemd-boot. Let's just > focus on why (or why not) vfat is the best option for $BOOT. > >>> Which file system do you have in mind even for this? >> >> Unspecified for now. i.e. no change. It would remain ext4 by default I >> expect, but ultimately whatever anaconda allows. > > So think about this one bit ahead. Right now it's clear that even with > Grub's relatively large contributor base it'shard to impossible to > support modern Linux file systems properly — even just for > read-only. See the the XFS debacle as one example, and that the kernel > folks made clear they only consider their own in-kernel implementation > to be supportable. Now, I'd assume that sooner or later features such > as boot counting are something we want for Fedora too (i.e. that we > can update the kernel, try to boot the new one a couple of times, and > when it fails all the time revert back to an older version, fully > automatically; in fact the fedora desktop have very recently started > work on that, though they have a weaker model of simply showing the > boot menu after failed boots, instead of reverting back). Now, in that > model you need to count the attempted boots somewhere. Thus you need > write access somewhere (and no, EFI variables don't work for this, > they are not suitable for stuff changed on every boot, as their memory > is generally not ready to be written too that often). Which hence > means you need write access to some file system in some form from the > boot loader. And how do you think that's going to work out if already > read access to modern file systems is, well, a desaster? > > Again, FAT is the one thing everyone can agree on. Boot loaders can > read it *and write it*, UEFI and raspberry pi firmwares have support > for it, and all OSes and their initrds generally too. > > From the Linux side we can provide relatively safe read and write > suppport for FAT. For example, if Fedora would use the systemd > automount logic for mounting $BOOT then the file system will generally > be unmounted, except in a small time window around actual > accesses. This means the chance that the file system remains in a > clean state is maxmized. > > $BOOT is a place to place very few files, with very simple access > patterns. Basically, during update cycles we just add a few files > there and remove some others, and they are written in one linear write > operation. For doing that we need no fancy file system features. The > simplest, most common file system storing files ist good enough for > that. You’ve done a great job stating requirements, but I think you’ve drawn the wrong conclusion based on the requirements. I’ll summarize: (a) The bootloader needs to be able to read $BOOT. (b) It would be nice if UEFI's filesystem layer supported $BOOT. (You would prefer if it were baked into firmware. Others might debate this requirement.) (c) $BOOT needs to be written when new kernels are installed. (d) It is useful to write to $BOOT from the bootloader to indicate that we're trying to boot and again from the booted system to indicate that the boot succeeded. (e) Writing $BOOT should be safe. (You said "relatively safe". I would argue that "as safe as possible against power failure and kernel panics" is better.) Let's also add: (f) The scheme should function without UEFI. There are plenty of non-UEFI systems out there. This means that the bootloader might need to live in a BIOS boot partition, or in flash, or in ROM, or in other strange places. (g) The bootloader's driver for $BOOT should implement at least reads and preferably writes compatibly with the kernel. (With the possible exception of F2FS, there are no crash-safe filesystems that meet this requirement, sadly.) (h) Putting $BOOT on RAID1 is extremely nice to have. Now let's think this through. You're proposing that $BOOT be the ESP. This fails (f) entirely. It fails (h) unless we use mdadm 0.9/1.0, but vfat + mdadm 0.9 and 1.0 fails (e) catastrophically. If we actually try to meet all the requirements, I think it's very hard to escape the conclusion that: 1. The bootloader itself cannot reside on $BOOT. 2. There needs to be a filesystem type that supports RAID1 and can be credibly implemented by Linux and by bootloaders. 3. That filesystem needs crash-safely. I think that the people trying to get BootLoaderSpec support into Fedora should try to get it right before it becomes a default and should actually try to solve this problem. And that solution should go upstream. I would propose the following: Fedora's BootLoaderSpec implementation must match a written spec. Not necessarily Lennart's or mjg59's, but it must be written down somewhere, clearly enough that a new, compatible implementation could be written. That spec must specify at least one MUST IMPLEMENT filesystem. I propose one of two choices: nilfs2 over mdadm 1.2 or F2FS over mdadm 1.2. Or ext4 if someone actually sucks it up and implements JBD2 support in GRUB *and* a permissively licensed UEFI driver for ext4 with JBD2 support. nilfs2 and F2FS have the major advantages that it's easier to implement them correctly than it is to half-ass the read support the way that bootloaders do for ext4. _______________________________________________ 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/HBBCVMDET2NO42JYAF5Q7UCCG37ABPIR/
