On Wed, Nov 13, 2019 at 6:54 PM Goffredo Baroncelli <kreijack@xxxxxxxxx> wrote: > > On 13/11/2019 18.00, Chris Murphy wrote: > >> The GRUB-fs should have the following main requirements: > >> - allow the atomicity guarantee > >> - allow molti-disk setup > >> - allow grub to update some file (grubenv come me as first) > >> - it should require a simple implementation (easy to porting to multiple system, which basically means linux, *bsd and solaris ?) > >> - the speed should be not important > > Plausibly we're most of the way there already, adapting the existing > > "BIOS Boot" partition. > > > Unfortunately the BIOS Boot partition (which means basically FAT), doesn't have support for "atomicity" nor multidisk.. It's definitely not FAT. It's a blob of space owned by the bootloader. No file system at all. As far as I know only the BIOS variant of GRUB uses it. But GRUB does have a way of detecting core.img on it, and avoids overwriting it by preferring to write in free space within that partition, ostensibly to support multiple instances of GRUB (multiple distributions), and some degree of atomicity as the core.img is written first to this partition before the boot.img or "jump code" is written in the first 440 bytes of the MBR. Obviously this is BIOS specific, which is also x86 specific. So it needs to grow to be more arch and firmware agnostic. But it's so simple it might actually be more practical than alternatives like a new file system or building a transactional based FAT. I'm sorta annoyed with the UEFI spec using FAT, having not solved the problem of atomic updating of the EFI System partition. But we could agree to only use the EFI System partition for the sole purpose of the firmware loading an EFI file system driver, immediately allowing the firmware to read/write to a more reliable file system. www.datalight.com/assets/files/secure/resources/Where%20Does%20FAT%20Fail%202016.pdf https://elinux.org/images/5/54/Elc2011_munegowda.pdf Those PDFs are kind interesting. -- Chris Murphy
