On Wed, May 10, 2023 at 03:52:51PM -0000, Luca Boccassi wrote: > > On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote: > > > > It sounds reasonable for sure. > > The only concern is, given Microsoft creates at most 500MB ESP > > partitions, are we sure all UEFI systems out there will not choke on a > > 1GB one? > > > > Can't we reduce the number of kernels by having *only* one UKI and a > > rescue one that can be used to restore the previous working UKI from > > /root if the active one fails? > > > > Or perhaps just have always 2 UKI (current, and former working). > > Do we actually need a separate dedicated rescue UKI? Can't rescue be > > implemented by booting the previously working UKI with a "rescue" > > command line option ? > > Word of caution on 'rescue' images: MSFT just had to essentially > render 10 years of recovery/install media unbootable due to the > black lotus vulnerability. It was not (and still is not) pretty. > > When there's signatures and verifications involved, you really > want an upgradable system. But if you set that whole infrastructure > up, there's really not that much difference left with an A/B scheme. If the idea to allow a UKI to contain multiple alternate, signed, cmdline line profiles gets accepted [1], then a "rescue" image won't neccessarily need to be a separate image anymore. There could just be an alternative cmdline that caused the initrd to launch in a "rescue" / "safe" mode, and that would be nicely complemented by an A/B scheme to cope with bad kernel upgrades. With regards, Daniel [1] https://github.com/systemd/systemd/issues/24539 -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
