On Tue, Nov 15, 2022 at 7:02 PM Colin Walters <walters@xxxxxxxxxx> wrote: > > > > On Fri, Nov 11, 2022, at 11:41 PM, Chris Murphy wrote: > > On Thu, Nov 10, 2022, at 6:08 PM, Robbie Harwood wrote: > >> Ben Cotton <bcotton@xxxxxxxxxx> writes: > >> > >>> By design, ostree does not manage bootloader updates as they can not > >>> (yet) happen in a transactional, atomic and safe fashion. > >> > >> As we've talked about before, it's not possible to make updates > >> transactional. It involves, per spec and depending on processor > >> architecture, updating multiple files in different directories, > >> potentially on different filesystems entirely, one of which is fat32. > > > > EFI/FedoraA > > EFI/FedoraB > > > > NVRAM bootorder uses A then B > > > > Update the bootloader in EFI/FedoraB > > > > At any point of failure, only the EFI/FedoraA bootloader path is used. > > Once everything in EFI/FedoraB is committed to stable media, set > > bootnext FedoraB. If the boot fails, automatic failback to FedoraA. If > > the boot succeeds, bootupd can change bootorder. B then A. > > I think it makes sense for us to make some use of BootNext indeed. However, this heavily overlaps with a potential move to UKIs, which effectively obviate this whole thread by dropping shim and grub out of the equation. It also overlaps with https://github.com/ostreedev/ostree/issues/2725 where ostree could potentially start using BootNext itself - and this is I guess strongly pushing things to be more integrated. (I'd tried to keep the two independent, but...) The problem as it stands with UEFI BootNext booting the kernel directly, as opposed to using grub2 or similar, is that it doesn't currently deal with loading initrd/kernel command line strings etc. There's people looking at solving those issues in a few different ways though so it may be less of a problem in the not too distant future. > (There's also an overlap in your proposal with fully redundant EFI partitions across multiple disks and how that would need to be handled, also something I'd hoped to support in bootupd explicitly) > > _______________________________________________ > 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 _______________________________________________ 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
