[systemd-devel] Running packagekitd on shutdown

[Bill Nottingham]

Lennart Poettering (lennart at poettering.net) said: 
> > very very early at boot /var might not be around yet. So maybe the
> > upgrade packs should be placed somewhere in the rootfs (or in /boot?
> > that might be a good idea actually if it fits...). Split-off /var is
> > nothing we can get rid of, and makes a lot of sense to support.
> 
> So, Kay and I discussed this a bit, and so here's what we'd like to suggest:
> 
> Place the actual upgrade packs in /var/lib/something/, and use a touch
> file in the root dir to for the next reboot
> (i.e. in style of /forcefsck and so so). That way we know from the
> earliest moment of boot where we have to boot into, but we don't have to
> place the large upgrade packs in the root fs. 
> 
> That means if PK wants to prepare for an upgrade it would just place the
> upgrade pack in /var/lib/something/ and touch /upgrade and that's it.
> 
> The generator would then be even simpler:
> 
> if (access("/upgrade", F_OK) >= 0) {
>         asprintf(&dest, "%s/default.target", argv[1]);
>         symlink("/lib/systemd/system/upgrade.target", dest);
>         free(dest);
> }
> 
> (plus some error checking...)
> 
> Generators get the path where they should place their generated unit
> configuration in as argv[1], hence the asprintf(). 
> 
> And we'd then like to ask you to place a tmpfiles fragment in
> /usr/lib/tmpfiles.d/ which includes the following line:
> 
> r /upgrade
> 
> That way we can be sure that the flag file is removed as soon as the
> root fs is writable.
> 
> The rest of the earlier suggestion would stay the same.

So, thinking about the UI of this, I'm assuming the flow would be.

1. PK notices updates that require this mechanism
2. PK asks 'Upgrade Now?'
2a. Yes -> step 4
2a. No -> continue session. (Perhaps a persistent notification here.)
3. On user-initiated shutdown/restart, ask again.
3a. Yes -> step 4
3b. No, reboot as normal. Notification returns on next login.
4. PK drops the flag in
5. PK reboots into upgrade
6. Upgrade reboots into system once done

The main points I'm addressing here:

1) You don't want to have to try and get all the infrastructure up to
ask what the user wants to do on boot; do this in the normal session.
2) You don't want to offer to upgrade on the next reboot, have the user
keep working, have a system crash/battery die/whatever, and then start
upgrading when the user reboots to finish their document.

You may already be heading this way in the design, but the gnome.org page
wasn't clear yet.

> So, we want to make clear that any kind of solution that does not use a
> proper recovery partition is merely a stop gap in our eyes. And due to
> that it probably makes little sense to standardize upgrade.target in
> systemd. It should hence be shipped along with PK.

Not to get too into the technical wonkery, but the problem with the
recovery partition and any advanced packaging system is that you may very
well need to update the recovery partition just to be able to install your
updates, depending on any underlying packaging changes.

Bill