[systemd-devel] Using systemd.offline-updates from an ostree based system

[Lennart Poettering]

On Do, 25.04.19 17:10, Richard Hughes (hughsient at gmail.com) wrote:

>  Hi all,
>
> I use the offline updates feature
> https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html
> in fwupd to install some kinds of firmware. I've just found out this
> doesn't work on Fedora SilverBlue as / is immutable and of course
> creating the /system-update symlink fails.

Hmm, the assumption was always that / was mutable if offline updates
are used to update /...

I have the suspicion the ostree folks might have some specific ideas
on how to do this in their environment?

> I'm using the offline update mode rather than updating "live" as I'm
> updating the keyboard controller itself, which means the keyboard (and
> power button!) is disabled and various things like ACPI battery
> reporting also get upset for the 30 seconds of flashing. I'm stuck for
> ideas. I suppose I could write a new boot entry (BLS?) that has a new
> kernel command line argument set to go into system-update.target (and
> patch src/system-update-generator/system-update-generator.c) although
> I don't think BLS has the concept of a "oneshot" entry that would
> delete after running it once.

What precisely is writable on those systems? Is /etc? You need
something that is accessible during early boot (i.e. right after the
transition from the initrd to the host OS). This excludes /var in the
general case, but includes /etc, / or /usr...

Note that the boot loader spec is not universally adopted. Fedora uses
something they call the boot loader spec, but it#s very different from
what bootctl, logind, systemd's shutdown code and sd-boot understand
and not compatible. They really should stop using the name in its
current state, it's just confusing.

The boot loader interface systemd undestands actually has support for
oneshot boots, see:

https://systemd.io/BOOT_LOADER_INTERFACE.html, see the
LoaderEntryOneShot EFI variable.

Given that GRUB doesn't support that and maybe you don't want to bind
yourself to EFI variables it's not the best approach anyway?

I mean, you could store the flag at the following places at least:

   1. EFI variables
   2. ESP
   3. /boot if different from ESP
   4. /
   5. /etc

About these:

I'd not make dynamic changes to ESP or /boot I must say (i.e. 2. +
3. from the list above). It should contain static data only I am sure,
only updated at system updates.

EFI variables (1. from the list above) sound great for that, but are
EFI specific. If that's fine though you could invent your own EFI
variable, then write a systemd generator that looks for them, and
boots into your special target and removes the EFI variable after
use. Given that that firmware updates are not done daily writing an
EFI variable sounds acceptable.

The root dir (i.e. 4. from the list above) is immutable for you, hence
doesn't really work.

Which leaves /etc (5. from the list above), but I don't know what
kind of restrictions ostree makes there.

Lennart

--
Lennart Poettering, Berlin