On Tue, Apr 5, 2022 at 3:42 PM Gregory Bartholomew <gregory.lee.bartholomew@xxxxxxxxx> wrote: > > On Tue, Apr 5, 2022 at 3:51 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> >> On Tue, Apr 5, 2022 at 11:47 AM Gregory Bartholomew >> <gregory.lee.bartholomew@xxxxxxxxx> wrote: >> >> > I haven't done a "default" Fedora Server installation in a long time, so I'm not sure how they are laid out. But I seem to remember /boot being a separate partition for a long time (it used to be required because some older BOISs couldn't read beyond a certain sector on the disk). Could not /boot be converted to the ESP (i.e. reformatted with FAT32) on such systems? >> >> No. It would need to be reformatted as FAT to be firmware readable. >> And thus this is an irreversible modification. There will be lengthy >> periods of time that are simply not crash safe. So the risk is >> probably unacceptably high that the user ends up abandoned on a >> deserted island, in which case it's better to just steer them toward >> the well understood and document process of reprovisioning (clean >> install time). Yes it's tedious, but it's well understood and very >> reliable, and that counts for more than convenience in QA terms. > > > I get where you are coming from. But I might have an idea about how at least the "There will be lengthy > periods of time that are simply not crash safe" problem could be addressed. > > What if upgrades from BIOS to UEFI mode *had* to be done from an installation DVD/Thumb drive? Doesn't matter, it still wouldn't be crash safe on its own. You'd have to design an upgrade utility that uses a journal such that any interruption can be resumed where it left off. Only that journal would know the actual state of the system at each step of the migration. That's a lot of work and pretty much out of scope. >Then there is a guaranteed way that the system can be booted (otherwise the user would not have been able to initiate the automated upgrade). But without a journal it wouldn't be resumable or reversible. Since none of our installation media are writable out of the box, we'd also have to redesign one that does. > Additionally, the upgrade process could make a dd backup of the previous /boot partition (and the 440-byte boot sector) before reformatting it. In the worst-case scenario, the backup of the BIOS bootsector and partition could be restored. Only if the upgrade utility is designed to do such a restoration, the current upgrade service knows nothing about that. This is non-trivial work. And users can just upgrade. How will they even know about migration or what the benefits are? There's insufficient incentive to do the migration, even if they were aware of it. I think it'd be a lot of effort for very few users. The problem is that BIOS systems cannot have new installations performed on them. This makes the proposal a removal of support, not a deprecation. Deprecation is an expression of disapproval, it shouldn't have a direct impact on users. It's notice that this will (soon) involve an impact on users. -- Chris Murphy _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
