On Wed, 24.08.11 02:04, Lennart Poettering (lenn...@poettering.net) wrote: > However, there are a couple of caveats: since the generators are called > 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. > Done! > > I wonder if we should standardize step #2 in systemd itself, so that > this becomes a well known target or so. So that other folks can use that > too, for example if people use scripted upgrades or so (this usecase has > come up before on the ML, so maybe we should standardize this...). Or > maybe we shouldn't standardize this since only a recovery partition is > the correct way to handle this. 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. I think the approach outlined above is probably a good solution if you need something quickly. However, I'd urge your experimenting with this first before pushing this into the distros. The furture should be a recovery partition, not upgrades from within. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel