Removing the old udev rules did indeed resolve the precipitating error and allow
a smooth boot.
I kept the files so I could recreate the boot dependency failure, so if anyone
has an idea as to what output would be useful for me to collect to diagnose the
strange emergency shell behavior, I can ta
It took a while to grep the vol_id culprit. It's probably this:
/usr/share/initramfs-tools/scripts/functions: elif [ "$FSTYPE" = "unknown" ]
&& [ -x /lib/udev/vol_id ]; then
/usr/share/initramfs-tools/scripts/functions:
FSTYPE=$(/lib/udev/vol_id -t "${FS}" 2> /dev/null)
__
Michael Biebl wrote:
> You have a broken/outdated 60-persistent-storage.rules in
> /etc/udev/rules.d. Why?
I don't know why. I pasted my package history for udev|systemd at the end of
the email.
> You have a device listed in /etc/fstab which doesn't exist during boot,
> Please double check if
Michael Biebl wrote:
>Am 26.07.2014 20:10, schrieb Brian Julin:
>> 3) If you enable "quiet" and run the recovery mode, you will get login
>> prompts
>> within a minute or two. You will get two login prompts running
>> simultaneously.
>> Once you hav
I just went through this ordeal myself. Here are some observations.
1) The problem causing the OP to enter emergency mode in the first place
is likely because systemd does not seem to (with current packages) want
to do anything with swap or non-root partitions that are referenced by
UUID in /etc
