Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
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(a)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...)
(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)