[systemd-devel] Possible systemd segfault switching from 216 to 219 in fedora upgrade
lists at colorremedies.com
Sat Mar 14 01:44:39 PDT 2015
On Sat, Mar 14, 2015 at 12:07 AM, Andrei Borzenkov <arvidjaar at gmail.com> wrote:
> В Fri, 13 Mar 2015 16:38:33 -0600
> Chris Murphy <lists at colorremedies.com> пишет:
>> 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.
> You do not really need snapshots for this. You just need extra space to
> copy current boot environment. Using snapshots just allows to do it
> with less space needed.
OSTree does this with existing filesystems without snapshots. But it
handles all the logic of tree naming, bootloader config, and using
hard links instead of full file copying, as well as performing the
Btrfs and LVM thin snapshots mainly optimize a number of things rather
than being a prereq.
More information about the systemd-devel