Not really a support question but an FYI in case others encounter the same issue.
I have 4 Linux and Win7 set up as multiboot using siduction grub. I just installed KXStudio over an old install and returned to boot my new December to update grub and only got a maintenance emergency login. I looked at the journal log and found it had failed due to trying to mount the partition with the new OS which now had a different UUID. Simply commenting out the partition in fstab allowed siduction to boot normally.
I'm sure I have installed a new OS before and been able to boot normally to run update-grub.
Is systemd more fragile than the old init in this regard?
It depends, how the entry for the partition is in your fstab.
Primary it has not many to do with systemd.
From journalctl:
Jan 22 06:12:40 brain systemd[1]: ^[[1;39mJob dev-disk-by\x2duuid-475816b0\x2dfa24\x2d4ff2\x2db16d\x2d3c9b8a1fe33c.device/start timed out.
Jan 22 06:12:40 brain systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-475816b0\x2dfa24\x2d4ff2\x2db16d\x2d3c9b8a1fe33c.device.
Jan 22 06:12:40 brain systemd[1]: Dependency failed for /media/disk1part6.
Jan 22 06:12:40 brain systemd[1]: Dependency failed for Local File Systems.
From fstab:
# UUID=475816b0-fa24-4ff2-b16d-3c9b8a1fe33c /media/disk1part6 ext4 auto,users,rw,exec,noatime 0 0
From blkid:
/dev/sda6: UUID="3756f770-98ae-4738-a3a0-2c20dbc20bc9" TYPE="ext4"
It's working now anyway. Thanks towo for looking.
Just a postscript to this; I just did another install of a different distro on a different partition which caused a very long boot when I returned to siduction. I checked the journal with journalctl -bx -p 3
Turned out the installer had formatted the swap partition causing it to have a different UUID. Found the correct new UUID with blkid, edited in to fstab, and all was good again. :)
I like journalctl, easier than sifting through /var/log/. 8)
Edit: The original problem may have had something to do with the new distro install changing the hardware clock to local time.