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

[Lennart Poettering]

On Fri, 13.03.15 17:59, Will Woods (wwoods at redhat.com) wrote:

(Warming up this rally old thread again, sorry for not responding more timely)

> > http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
> > 
> > systemd has been implementing this for quite a while, at least for all
> > systems fedup should care for. In this scheme you mark the system for
> > upgrades, you reboot using the old kernel/initrd. This will now enter
> > the special upgrade mode, where you make your changes, and then you
> > reboot again with the new kernel.
> 
> Yeah, I really wanted that to work, but... when you're replacing
> literally the entire system *while* part of it is running, stuff gets a
> little weird.

Well, i doubt there's a way around it if you want this to work at all.

I mean, the point of the system updates stuff was to only run
early-boot services, i.e. udev, journald and systemd itself, whatever
storage needs, nothing else. Are these really that problematic?

> All my efforts to make major-version upgrades work from the
> system-updates hook ended in weird crashes due to libraries being
> replaced out from under running binaries, etc.
> 
> At this point people usually say: "Hmm, maybe you need a minimal system
> you can chroot into and run the upgrade from?"
> 
> ..and that's exactly what the upgrade.img initramfs is! We just need to
> be able to switch-root from your running system into an upgrade image..
> *WITH* your disks mounted in it.

But we will not support something like this sorry. Not with full
serialization/deserialization. This cannot work. We will not support
two-way version transitions like this. Sorry.

I also have doubts this will really work. Much of the storage stuff
cannot just be left around without its backing daemon. Hence you need
to leave those daemons around, and there you go: you will still have
old stuff in memory then.

> 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

Well, we don't allow access to devices from containers. The kernel
does not virtualize access to it, and we will not pretend it
does. Sorry, this cannot work either. 

There can raelly only be one udev daemon that manages devices, not two...

Lennart

-- 
Lennart Poettering, Red Hat