I am not convinced that the cgroup issue was the only issue here, but
since this is a single physical I can't easily go back in time to test
further.
Either way the changed summary is backwards. Once repartitioning was
completed systemd fails to boot if the /dev/cgroup fstab entry IS
present.
Th
> cgroup /dev/cgroup cgroup defaults 0 0
Erk -- that's what broke the boot after all? Indeed, this was in comment
4 already, but I missed that. So the journal should have a
complaint/timeout on that, as /dev/cgroup is a thing of the distant past
(google still has a few hits). Thanks for finding!
I dug into this more on the server that failed to upgrade properly to
see if the server would work properly after switching back to systemd.
Please recall this was after a backup and restore with a much simpler
partitioning scheme. It still would not boot.
I ended up finding this line in my fstab:
> So what I can do is to install a 14.04 system with LVM and separate
/home, /tmp/, /usr, and /var, upgrade that to 14.10 and 15.04, and see
if I can reproduce this.
I just did that, and the upgrade worked without a hitch. So I'm afraid
we still don't have a reproducer for this..
/dev/vda1 on /bo
>I've been working with Linux for 20 years, I really doubt there was
anything wrong with my fstab.
systemd reports errors which sysvinit and upstart just ignore (i. e.
silently ignoring wrong UUIDs, and just not pointing that partition,
etc.). We got a lot of bug reports due to that, which is why
