On Fri, Mar 27, 2020 at 1:56 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > Where would mock be executing from? The same filesystem it is modifying? > Somehow it seems that this doesn't change much, but just brings > in another layer. Or will a complete copy of the system be made in > memory to execute the upgrade tools from? Snapshot it. If it doesn't work, throw away the snapshot. > > Let's consider a concrete example that came up recently: grub wants to > rewrite something in the bootloader area on disk to help upgrades from > very old installations. In current "offline upgrade" scheme, the upgrade > tools are running on the real system, with udev active. They can query > and touch hardware, can see all the disks as they are, etc. If we > went through mock, it'd be running in an nspawn environment w/o access > to hardware. This particular example affected BIOS GRUB, where the embedded "core.img" isn't ever updated. i.e. grub-install is called once at original install time, and never again. I'm not certain whether installation is, or could be, atomic. On UEFI, the "core.img" makes up most of grubx64.efi, and it's updated anytime grub2-efi-x64 package is updated. Not only system upgrades. I don't know how RPM replaces it. But since it's on FAT, atomicity is limited to the VFS operation. There is a window where it could be interrupted and things wouldn't be in either working state. > (Something like os-tree's atomic replacement of things, that's of > course a completely different story. But so far we're talking about > traditional systems.) Perhaps ironically, rpm-ostree + UEFI systems, don't have the bootloader updated. And it doesn't really want to be responsible for it. GRUB is very cool in many ways, but having a strategy for keeping itself up to date is not one of them; so far upstream GRUB development considers this a distribution problem, not a problem in search of a generic solution. One idea is a service that ensures boot related things are in the proper state, including mirroring the EFI system partition for raid1 sysroot setups. It's not decided if it should be fwupd function or made into a separate boot daemon. -- 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
