On Fri, Mar 13, 2015 at 3:59 PM, Will Woods <wwo...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
