On Tue, Nov 15, 2022 at 7:02 PM Colin Walters <walt...@verbum.org> 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 <bcot...@redhat.com> 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
