This bug is splitting out the systemd part of https://bugzilla.redhat.com/show_bug.cgi?id=1195899 .

Also see https://bugzilla.redhat.com/show_bug.cgi?id=1195761 , which is a different bug caused by the same change.

After systemd 219 landed in Fedora 22, we noticed that nightly live images would sometimes fail to boot, due to a kernel null pointer dereference.

On further investigation we noted that systemd-219 does some stuff to run-initramfs-squashfs.mount which systemd-218 does not. These messages appear when booting the 2015-02-21 and later nightlies:

Feb 24 20:03:30 localhost systemd[1]: Unit run-initramfs-squashfs.mount is bound to inactive unit. Stopping, too.
Feb 24 20:03:30 localhost systemd[1]: Unmounting /run/initramfs/squashfs...
Feb 24 20:03:30 localhost umount[526]: umount: /run/initramfs/squashfs: target is busy
Feb 24 20:03:30 localhost umount[526]: (In some cases useful info about processes that
Feb 24 20:03:30 localhost umount[526]: use the device is found by lsof(8) or fuser(1).)
Feb 24 20:03:30 localhost systemd[1]: run-initramfs-squashfs.mount mount process exited, code=exited status=32
Feb 24 20:03:30 localhost systemd[1]: Failed unmounting /run/initramfs/squashfs.
Feb 24 20:03:30 localhost systemd[1]: Unit run-initramfs-squashfs.mount is bound to inactive unit. Stopping, too.
Feb 24 20:03:30 localhost systemd[1]: Unmounting /run/initramfs/squashfs...
Feb 24 20:03:30 localhost umount[529]: umount: /run/initramfs/squashfs: target is busy
Feb 24 20:03:30 localhost umount[529]: (In some cases useful info about processes that
Feb 24 20:03:30 localhost umount[529]: use the device is found by lsof(8) or fuser(1).)
Feb 24 20:03:30 localhost systemd[1]: run-initramfs-squashfs.mount mount process exited, code=exited status=32
Feb 24 20:03:30 localhost systemd[1]: Failed unmounting /run/initramfs/squashfs.
Feb 24 20:03:30 localhost systemd[1]: Unit run-initramfs-squashfs.mount is bound to inactive unit. Stopping, too.
Feb 24 20:03:30 localhost systemd[1]: Unmounting /run/initramfs/squashfs...
Feb 24 20:03:30 localhost systemd[1]: Unmounted /run/initramfs/squashfs.
Feb 24 20:03:30 localhost systemd[1]: Unit run-initramfs-squashfs.mount entered failed state.
Feb 24 20:03:30 localhost systemd[1]: run-initramfs-squashfs.mount failed to run 'mount' task: No such file or directory
Feb 24 20:03:30 localhost systemd[1]: Failed to mount /run/initramfs/squashfs.
Feb 24 20:03:30 localhost systemd[1]: Mounting /run/initramfs/squashfs...

No such messages appear when booting 2015-02-18 and earlier nightlies.

After poking through various dracut and systemd changes, I came to suspect this systemd commit:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=06e97888883e2cc12eb6514e80c7f0014295f59b

when I went to build a systemd package with it reverted for testing, I found that cgwalters had beaten me to it:

http://koji.fedoraproject.org/koji/buildinfo?buildID=614715

so I built a live image with that systemd-219-5.fc22 package. Indeed, it boots successfully on multiple attempts, and does not have the log messages listed above.

I have left #1195899 open because the kernel should not crash when this happens, obviously, but it's systemd that changed its behaviour, and it doesn't seem like this 'try multiple times to unmount /run/initramfs/squashfs then re-mount it' behaviour is actually what we *want*, so I believe there are two bugs - the kernel crash, and this behaviour from systemd - and as systemd is the one that changed and the new behaviour really looks wrong, it should be the higher priority to fix.

The revert in 219-5 does seem to address this issue, but I'm guessing that won't be considered the 'correct' long-term fix, so it seems a good idea to have a bug open.

Proposing as an Alpha blocker: conditional violation of "All release-blocking images must boot in their supported configurations."