This shouldn't have been marked invalid. It has caused me and apparently others
grief. It wouldn't be hard to have the upgrade tool check for uncommented
cgroup lines, given they blow up an upgrade.
I'm glad my experience and work around helped someone else who ran into the
same things.
--
You
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
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:
faults 0 0
UUID=99649f74-7be3-427a-9eef-65a1b2922196 /mnt/tmp xfs
defaults 0 0
All a journalctl -b would gather now would be the boot log data 9 days
after this was all fixed. The log only goes back 3 days. The blkid would
capture uuids for the new partitions. Do y
Please note attempting to mitigate this by switching back to upstart
failed as well.
Doing so did make it so the system would boot past mounting /usr however
for no obvious reason the system stopped automatically mounting the /var
partition.
With no network services running, the system would stop
Public bug reported:
I recently upgraded a server from 14.10 to 15.04. The upgrade claim to
have worked but the system could not boot afterwards.
Basically when you attempt to reboot you end up at an emergency maintenance
prompt early in the boot process.
After a lot of digging one of the messag
6 matches
Mail list logo
