Page MenuHomeSolus

dracut / systemd-cryptsetup error
Closed, ResolvedPublic

Description

I just installed the latest updates that synced today (8/19). I'm running linux-current, and have full-disk encryption setup.

On boot, the LUKS screen now presents a message like the following:

dracut-initqueue[358]: Failed to start systemd-cryptsetup<big string of chars>.service: Unit systemd-cryptsetup@luks<big string of chars>.service failed to load: No such file or directory.

I actually can type in my password and still get to the main login screen and into Solus/Budgie. But, I've never seen this before so wanted to report it.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
JoshStrobl triaged this task as High priority.Aug 19 2017, 5:20 PM
JoshStrobl added a subscriber: JoshStrobl.

Able to reproduce here.

JoshStrobl edited projects, added Software; removed Lacks Project.Aug 19 2017, 5:20 PM
JoshStrobl moved this task from Backlog to System and Configuration Fixes on the Software board.
upnix added a subscriber: upnix.Aug 20 2017, 11:20 AM
Zeqrex added a subscriber: Zeqrex.Aug 20 2017, 8:10 PM

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?

sd added a subscriber: sd.Sep 12 2017, 9:37 PM
linuxworks4me added a comment.EditedSep 23 2017, 10:37 AM

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...

xeboc added a subscriber: xeboc.Oct 3 2017, 7:23 AM
rawbone added a subscriber: rawbone.Oct 8 2017, 6:54 PM
Unknown Object (User) added a subscriber: Unknown Object (User).Oct 10 2017, 5:11 PM
Cortys added a subscriber: Cortys.Nov 4 2017, 4:47 PM

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.

nr4400 added a subscriber: nr4400.Nov 25 2017, 10:19 PM
mclang added a subscriber: mclang.Nov 28 2017, 3:09 PM

Hello, same issue here on a fresh install.

Daniel added a subscriber: Daniel.Dec 20 2017, 12:15 PM
mclang added a comment.EditedDec 22 2017, 8:23 AM

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?

palto42 removed a subscriber: palto42.Dec 22 2017, 9:30 AM

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....

jgrnh added a subscriber: jgrnh.Dec 26 2017, 9:28 AM

Able to reproduce from first update after a clean install.

ikey added a comment.EditedJan 1 2018, 4:27 PM

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?

clauded added a subscriber: clauded.Jan 4 2018, 3:06 AM

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.

daper added a subscriber: daper.Jan 9 2018, 11:22 PM

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?

xeboc added a comment.Jan 10 2018, 8:32 AM
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?

mclang added a comment.EditedJan 10 2018, 11:20 AM

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
clauded added a comment.EditedJan 10 2018, 12:48 PM

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

hubris added a subscriber: hubris.Jan 23 2018, 12:25 AM

I have /etc/crypttab.

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

daper added a comment.Jan 23 2018, 8:44 AM

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.

Yannnd added a subscriber: Yannnd.Feb 13 2018, 6:18 PM

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.

siru added a subscriber: siru.Feb 19 2018, 7:01 PM

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

daper added a comment.EditedFeb 21 2018, 9:26 AM

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/....
ikey closed this task as Resolved.Feb 24 2018, 12:59 PM
ikey claimed this task.

Confirmed as fixed in unstable thanks to the work by @daper - cheers bud :)