On Fri, Mar 27, 2020 at 1:56 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> 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