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 _______________________________________________ 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/L4Q7ILZRWGWGVH77UCVMWG52FMATLR5X/
