On Mo, 06.07.20 21:58, Peter Robinson (pbrobinson@xxxxxxxxx) wrote: > > > > Less complexity in the boot chain, mainly. But the EFI drivers would > > need to be signed by MS, I think? That would massively complicate > > things. > > I believe that to be correct, of could Apply has control over that for > their platform, you'd also need to load them some how, I'm guessing > sd-boot could try loading/locking if it can't read a file system... > suddenly things start to head towards complexity again. Quite frankly, I don't see the point of using a different file system than VFAT here. You cannot avoid VFAT anyway, since that's the only thing EFI firmware can generally read, and hence your boot loader itself is always read from VFAT anyway. Throwing in another file system just increases the maintenance burden: previously you had one problem and now you have two problems. Given that the update cycles for boot loaders in a world where boot loaders do certificate management, TLS, HTTP, networking, IP, yadda yadda isn't much different from update cycles for kernels/initrds adding in a second, separate file system such as XFS or ext4 won't give you much additional data safety, it just gives you more code that can break. In particular as features such as boot counting/assessment require writable fs access from the boot loader, but that is very hard to tackle on journalling file systems (grub doesn't do it afaik), and basically means you need to maintain your own fully blown file system implementation. VFAT on the other hand is simple, its there anyway, you need to rely on it anyway and allows writing from firmware too. That all said, one feature I'd like to add to sd-boot is that we define a drop-in dir where you can put drivers in, and we'll load them all, one by one. The idea would be that distros can drop in XFS or ext4 drivers there, properly signed, and we'd load them, so that it doesn't matter to sd-boot which file system you actually pick: if you want XFS or ext4 then you can easily make it happen, just by dropping in their driver files, and things will just work. Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
