Hi,
From my perspective (Fedora CoreOS developer) that straddles
both physical and cloud for the server case, the problem is that
the virtualized case, and in particular public cloud, and really
specifically EC2 - no one really cares about EFI to boot their VMs.
Indeed. And it sucks.
> Device Start End Sectors Size Type
> /dev/sda1 2048 10239 8192 4M BIOS boot
> /dev/sda2 10240 1058815 1048576 512M EFI System
I wouldn't *oppose* that; in fact if you (or someone else)
wanted to push for that with e.g. Fedora CoreOS, I'd be happy
to discuss it. But it's not like it has a truly compelling advantage
over what we ship today - it'd just be *another* weird variant
of things in the end right?
Well, as *additional* variant it doesn't provide that much value. More
interesting would be to create all x86 cloud images that way, so they
boot just fine on both bios and efi, and we don't have to bother
creating two image variants.
And the fact that FAT has no ability to do atomic replacement
bothers
me a lot. (A wrinkle here is that ostree implements an atomic swap of
/boot/loader - you can today boot FAH/Silverblue and just ls -al /boot
to see it)
Why do you need that? Wouldn't FAH just drop a new file for the new
version into /boot/loader/entries on updates? So you have old and new
version listed in the boot menu and can easily rollback to the old
version if needed?
But anyway: The scheme works with and without separate /boot.
cheers,
Gerd