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

[Lennart Poettering]

On Mon, 09.03.15 08:10, James Hogarth (james.hogarth at gmail.com) wrote:

> >> The reason for this is to simplify finding out where mount points are
> >> for a clean upgrade - it's been felt the easiest way is to just 'ask'
> >> the actual system to do this.
> >>
> >> After the mount points are all up switch-root is used to switch back
> >> to the initrd setup so that the upgrades can be carried out on teh
> >> non-running system... so we have a systemd-216 to 219 transition here.
> >>
> >> This naturally means that the serialization/deserialization needs to
> >> be forwards *and* backwards compatible between 216 and 219 for this to
> >> work.
> >
> > Yeah, but no. Allowing uprgades is one thing, allowing downgrades a
> > completely different one, and nothing we want to support.
> >
> >> >From the logs that I've pulled (see the various attachments in
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1185604 for them) it would
> >> appear the 219 -> 216 process is fine but then switching back from 216
> >> -> 219 is failing with the associated segfault.
> >>
> >> There appears to be a couple of options here:
> >>
> >> 1) Try to get a workable reduced test case or better debugging from
> >> the 216 -> 219 transition to work out why that is failing.
> >> 2) Have some sort of generator or call or similar that allows the
> >> systemd-newer in the initrd to parse the unit files and fstab of the
> >> installed system and carry out any mounting itself rather than using
> >> switch-root to the installed system and asking it to do so. This would
> >> then eliminate the jumping backwards and forwards between systemd
> >> versions during the upgrade process.
> >
> > I am not really sure I follow here...
> >
> 
> So the question and requirement that is attempting to be filled is:
> 
> In the fedup initrd environment mount all filesystems the system being
> upgraded has.
> 
> Given the mix between fstab, mount entries and GPT generated the
> tricky thing is how to ensure all relevant filesystems are mounted
> before the upgrade process is called to ensure that all files covered
> by the rpms do get updated and nothing get accidentally left out.
> 
> Following along the idea of some sort of service to parse fstab, mount
> units and GPT type gets you to something approaching the already
> solved problem of how systemd handles mounts overall. So the approach
> taken was to just switch-root to the installed system's systemd and
> let it run it's generators and so on to handle the mounting itself and
> then after that is complete switch-root back out to the fedup
> environment to carry out the actual upgrade offline.

I'd really avoid having to different paths to get everything mounted,
if you want this to be robust.

My recommendation would be to use the offline updates logic we have in
systemd already:

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.

> Analysis of that makes it clear it's the mkdir_p_label function that
> causes libselinux.so to do a type lookup on the path to segfault (at a
> strcmp in selinux_sub) which then bubbles back up as an underlying
> issue in this case. 

Do you have a full backtrace for this?

Which mkdir_p_label() invocation is this?

Lennart

-- 
Lennart Poettering, Red Hat