[systemd-devel] Possible systemd segfault switching from 216 to 219 in fedora upgrade

[Chris Murphy]

On Fri, Mar 13, 2015 at 3:59 PM, Will Woods <wwoods at redhat.com> wrote:
> I don't really like the new->old->new switchroot stuff, but I haven't
> got a better solution at the moment.
>
> But: if we could use something like "systemd-nspawn" to:
>
> 1) start your old system in a container,
> 2) let it mount its disks,
> 3) copy/bind/move those mounts back out to the host somehow

Quite a while ago I suggested to Richard Hughes the idea of using
systemd-nspawn and snapshots to get fully atomic updates when on LVM
thinp volumes or Btrfs. It can work for major upgrades also.

First snapshot existing trees, start a container, mount the snapshots,
update/upgrade them. If it fails, destroy the snapshots. If it
succeeds, update bootloader config to boot the snapshots, and notify
user for reboot.

A further refinement could even be a systemd-nspawn "reboot" of the
upgraded snapshots as a test. If that fails, log some details of the
failure, destroy the bad snapshots. If it succeeds, update bootloader
config.

In any case, the existing fs trees are untouched. So it also
eliminates the multiple reboots requirement, and even eliminate the
necessary timely reboot. The user can continue to fully use the
existing tree indefinitely. It's similar to OSTree/Project Atomic in
concept.

This is actually my usual update procedure, except I've only done it
old school style with chroot so far. Container would be a more
deterministic environment and thus more reliable I think. Both Btrfs
and LVM thinp snapshots are completely independent fs trees, so
there's no parent-child distinction, which is what makes this upgrade
process viable.

-- 
Chris Murphy