On 14 Apr 2020, antlists@xxxxxxxxxxxxxxx stated: > The CPU starts, jumps into the mobo rom, and then looks for an EFI > partition on the disk. Because it understands VFAT, it then reads the Side note: technically it doesn't understand VFAT, exactly, and some vendors (e.g. Apple) provide entirely separate drivers to read the ESP. However, the fs is *very close* to VFAT (actually FAT32), and in practice Linux's vfat driver works fine. See s13.3 "File System Format" in <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf> (and similarly-named sections in earlier spec versions). > I don't quite get this myself, but this is where it gets confusing. > EFI I think offers you a choice of bootloaders, which CAN include > grub, which then offers you a choice of operating systems. But EFI can > offer you a list of operating systems, too, which is why I said why > did you want to use grub? ... which is why I don't. In my experience grub(2) is just another thing to go horribly wrong on an EFI system, with yet *another* set of driver reimplementations, some of which are downright dangerous. (The XFS one, for instance, which at one point assumed it could just access the fs as it was on the disk, when you can't do any such thing without replaying the journal first: XFS explicitly does not flush the journal on shutdown because it's a waste of time, given that the journal must always be present to access the fs anyway: but this means that accessing the fs without going through the journal can omit any number of transactions, quite possibly including the transactions that wrote out the kernel you expected to be booting. Thankfully XFS has since evolved to the point where grub simply can't read the fs at all -- sparse inode allocation and CRC'd metadata both break it -- so the temptation to try to use it on such filesystems is removed.)
