Exact same thing happening for me. The error came up after the linux-current update from 4.12.7 to 4.12.8

I updated my other laptop which is running the lts kernel to the latest sync and get the same error/message. So this isn't something specific to the current kernel, fwiw.

Is the message "watchdog: watchdog0: watchdog did not stop!" related to this? (T4359). Both warnings came after update.

Same here. After the latest update to 4.12-8.13 I have the same issue. If I choose 4.12-7.11 to boot from the problem does not occur. I'm asked for the crypt password without error message. If I choose the default 4.12-8.13 option the problem occurs again.

I also wanted to confirm this bug. Is this command able to fix/related to the issue?

After 4.12-9.14 the workaround of choosing the previous kernel version no longer works. After pressing enter once you can still enter the encryption password and continue starting up. Is there any news on this?

Seems to me the dash in the disk uid gets converted to "xtd", thats why the partition can't be found?

Is this a misconfiguration in grub, dracut or systemd? I've been trying to figure it out, bu no luck so far...

I just wanted to drop a note that with the most recent sync (thanks!), in which I saw that dracut/systemd/cryptsetup were updated, this issue still exists. Not complaining, I'm juts not sure whether it was possible any of those updates would resolve this.

Hello, same issue here on a fresh install.

Is there a way to fix this manually, e.g modifying somehow the boot options?

I tried looking through the dracut services I found, but here was no mention of cryptsetup things in there.

Can I somehow regenerate the string hash and put it in right place?

Could running systemd-cryptsetup-generator help?

Can I lock myself out of my FDE setup if I run that?

Its already run during the boot up.

In T4336#96974, @ikey wrote:

Its already run during the boot up.

Okay _now_ I understand what I am reading from the man page....

Able to reproduce from first update after a clean install.

Alright lets stop with the "me too" club

i.e. we need more details, not more confirmations, we know its an issue :)

@ikey Here's my task about it: T5426

How can I give more details?

I did a clean install last night (Budgie). After running updates and rebooting, I get a similar error, but instead of .service failed to load: No such file or directory, I get .service not found.

I enter the LUKS password and then get a kernel panic.

If I switch back to kernel 4.12 in GRUB, I'm able to log in fine.

I'm posting this here because it seems related, but I can open a separate issue if that's more appropriate.

Hi all! I was annoyed too by the failed to load message on boot. And I finally get it gone. The trick is to replace in the boot line rd.luks.uuid=[...] by luks.uuid=[...]. Don't ask :) it just works. I more or less have an idea of why after reading the man page of systemd-cryptsetup-generator... But I wonder if anyone could give the exact explanation.

I tried this also.

I edited /boot/loader/entries/Solus-current-4.14.12-44.conf directly and it worked... sort of. The error message disappeared, but for some reason the system does not boot up after I enter my root encryption key.

How to do this properly and in a way that the change sticks also over kernel updates?

In T4336#99396, @daper wrote:

Hi all! I was annoyed too by the failed to load message on boot. And I finally get it gone. The trick is to replace in the boot line rd.luks.uuid=[...] by luks.uuid=[...]. Don't ask :) it just works. I more or less have an idea of why after reading the man page of systemd-cryptsetup-generator... But I wonder if anyone could give the exact explanation.

Not yet testet, I'm at work. But I honestly do not know how can it still work after changing rd.luks.uuid to luks.uuid, shouldn't be this message reported by a ramdisk hook (and therefore aren't we running still from the ramdisk) ?

From man page:

rd.luks.uuid= is honored only by initial RAM disk (initrd) while luks.uuid= is honored by both the main system and the initrd.

If we connect this issue to the other one where system hangs on log in and this it may suggest there is something weird going on with remounting rootfs.
Can somebody having one of those issues post output of cat /proc/mounts?

Here is mine:

$ cat /proc/mounts
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=4051956k,nr_inodes=1012989,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/unified cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,name=systemd 0 0
efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
/dev/mapper/SolusSystem-Root / ext4 rw,relatime,data=ordered 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=42,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime,pagesize=2M 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
/dev/loop0 /snap/core/3604 squashfs ro,nodev,relatime 0 0
/dev/loop1 /snap/core/3748 squashfs ro,nodev,relatime 0 0
/dev/loop2 /snap/core/3440 squashfs ro,nodev,relatime 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=819836k,mode=700,uid=1000,gid=1000 0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
/dev/sda1 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro 0 0

@mclang Your mounts look fine, is it after changing rd.luks.uuid to luks.uuid?

Here's mine.

$ cat /proc/mounts
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=3943172k,nr_inodes=985793,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/unified cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,name=systemd 0 0
efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
/dev/mapper/SolusSystem-Root / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=47,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime,pagesize=2M 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=798080k,mode=700,uid=1000,gid=1000 0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0

In my case, the error message is gone after changing rd.luks.uuid to luks.uuid. I used grub-customizer but it won't survive kernel updates.

My mounts are when I have rd.luks.uuid.

If I change it to plain luks.uuid, my PC does not resume normal booting after I input my decryption password.

Could it be related to the absence of /etc/crypttab?

https://dev.solus-project.com/T4793

I have /etc/crypttab.

It did not exist straight after installation though, I created it myself for my home partition.

I also have /etc/crypttab. I've created by myself during the os installation... But yes, solus-installer does not create it. Anyway I have the error too if I boot with rd.luks.uuid or with rd.luks.crypttab=no.

So, I did some digging on this and found a related bug report on redhat.com: https://bugzilla.redhat.com/show_bug.cgi?id=1531507

Seems to be a dracut bug, which doesn't escape backslashes for systemd unit names. dracut fixed it here: https://github.com/dracutdevs/dracut/commit/0f6d93eb9d63695a64002ec8b0421fbc9fc8a7a3

So the systemd escape of "-", which is "\x2d" gets converted to "x2d" in dracut. The unit cannot be found then.

I tried to apply the patch to the file /usr/lib64/dracut/modules.d/90crypt/parse-crypt.sh but the file is different than the one from RH. I also tried adding 'luksname="$(str_replace "$luksname" '\' '\\')' at line 66 in the file and reboot but the boot error is still displayed. I guess the fix must be applied somewhere else or differently.

Upstream released Dracut 047 yesterday and it contains mentioned commit.
Maybe someone affected by this bug could upgrade package and check if it helps?

Nice! The new Dracut 047 seems to have solved the issue for me. Steps:

• Configure line: ./configure --sysconfdir=/etc --disable-documentation
• Then issued dracut and placed the newly created image on the right place at /boot/....