initramfs files build with dracut-034-r1 tries to open all (?) found LUKS devices. I've two HDDs in my system. 1st contains the rootfs (including /usr) encrypted with a pass phrase, the 2nd contains the whole other stuff encrypted with a key file. In former times the pass phrase for the 1st HDDs was asked via prompt and the 2nd HDD was opened during boot process by systemd over crypttab. Now the 2nd HDD is tried to be opened by the scripts in initramfs which fails, because the initramfs doesn't contains the key file. Even if I add the file via 'install_items+=', I get the prompt for opening the 2nd HDD. I've to press enter-key five times to continue the boot process. I've also added 'rd.luks.uuid=' to kernel command line with just the UUID of my 1st HDD, but it seems the scripts ignoring the parameter.
I've restored the ebuilds of older versions. Last version where it works, is 'dracut-031-r1'
Can you git bisect it?
Could you test with 036?
The first test with 036 didn't work. The image complains about missing symbols for a systemd service. That's a new/different bug.
Any news on this bug?
If upgrade to a newer version doesn't help, please provide rdsosreport.txt file: Add 'rd.break rd.debug log_buf_len=1M' to the kernel command line. Dracut will drop you to an emergency shell. Then copy /run/initramfs/rdsosreport.txt to persistent storage (e.g. to /boot) and attach to this bug report.
(In reply to Alexander Tsoy from comment #6) > If upgrade to a newer version doesn't help, please provide rdsosreport.txt > file: > Add 'rd.break rd.debug log_buf_len=1M' to the kernel command line. Dracut > will drop you to an emergency shell. Then copy > /run/initramfs/rdsosreport.txt to persistent storage (e.g. to /boot) and > attach to this bug report. I've tried the last 'dracut-034-r4'. When booting the system without special parameter I get following error: 'dracut-initqueue[269]: Failed to issue method call: Unit systemd-cryptsetup@luks\x2d34deb499\[...].service failed to load: no filev or directory.' When I try to enter my passphrase I get the same error message again. When booting the system with your kernel parameters I see debug output of the initramfs running through the console. It seems the script hangs in an infinite loop. I'd no chance to enter the emergency shell
This means that systemd-cryptsetup@******.service was not generated by systemd-cryptsetup-generator. Try to add something like "rd.break rd.debug log_buf_len=1M systemd.log_level=debug rd.retry=16" to the kernel command line. If that doesn't help, try reducing the retry value. It's 180 by default. :)
Created attachment 372712 [details] bootlog dracut-034-r4 The attachment contains the bootlog of initramfs. 'systemd.log_level' didn't worked correctly; I didn't see anything. The bootlog is without this parameter.
Mirko, thanks! It seems the problem was introduced with commit [1]: + cmdline >> "${initdir}/etc/cmdline.d/90crypt.conf" So all encrypted volumes are stored in /etc/cmdline.d/90crypt.conf and dracut generates udev rules for all of them. From your rdsosreport: [ 1.742651] hive dracut-cmdline[135]: ///lib/dracut/hooks/cmdline/30-parse-crypt.sh@16(source): LUKS='luks-34deb499-56bd-47de-bf15-7b86278114a5 luks-f7a0db53-a2ae-40f4-9f60-7bdd8fc8ed91' ... Two possible solutions: 1. Enable hostonly mode. /etc/crypttab will be included in the initramfs and parse-crypt.sh will skip all luks devices from crypttab. 2. This also should be fixed by recently introduced -[-no]-hostonly-cmdline option [2] [3]. So this bug will be fixed in dracut-037, because hostonly-cmdline is disabled by default. Also would be nice if you test dracut-9999 from "aidecoe" overlay. Thanks! [1] http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=1743473b2b7c1fb09b9eddc11d33fb3269877529 [2] http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=ab9457efd78ff74c654b4123956cdbd131935066 [3] http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=646e0506f6887db7811694c2c72ba5e516025993
(In reply to Alexander Tsoy from comment #10) > Two possible solutions: > 1. Enable hostonly mode. /etc/crypttab will be included in the initramfs and > parse-crypt.sh will skip all luks devices from crypttab. > 2. This also should be fixed by recently introduced -[-no]-hostonly-cmdline > option [2] [3]. So this bug will be fixed in dracut-037, because > hostonly-cmdline is disabled by default. I always run dracut with the '-H' parameter, so option 1. seems not be a solution. I'll check what happens without that parameter.
Ah.. crypttab_contains() search lines in crypttab by UUID and you probably don't have UUID in crypttab. That'a why hostonly mode makes no sense.
When creating the initramfs without '-H' parameter the system don't comes up and don't enter the emergency shell. The last output is: '/bin/dracut-cmdline@71(): exit 0'
(In reply to Alexander Tsoy from comment #12) > Ah.. crypttab_contains() search lines in crypttab by UUID and you probably > don't have UUID in crypttab. That'a why hostonly mode makes no sense. Proof: [ 1.749154] hive dracut-cmdline[135]: //lib/dracut-crypt-lib.sh@9(crypttab_contains): local luks=34deb499-56bd-47de-bf15-7b86278114a5 [ 1.749824] hive dracut-cmdline[135]: //lib/dracut-crypt-lib.sh@10(crypttab_contains): local l d rest [ 1.750476] hive dracut-cmdline[135]: //lib/dracut-crypt-lib.sh@11(crypttab_contains): '[' -f /etc/crypttab ']' [ 1.751088] hive dracut-cmdline[135]: //lib/dracut-crypt-lib.sh@12(crypttab_contains): read l d rest [ 1.751686] hive dracut-cmdline[135]: //lib/dracut-crypt-lib.sh@13(crypttab_contains): strstr data 34deb499-56bd-47de-bf15-7b86278114a5 [ 1.752333] hive dracut-cmdline[135]: //lib/dracut-lib.sh@25(strstr): '[' data '!=' data ']' [ 1.752998] hive dracut-cmdline[135]: //lib/dracut-crypt-lib.sh@14(crypttab_contains): strstr /dev/sdb1 34deb499-56bd-47de-bf15-7b86278114a5 [ 1.753606] hive dracut-cmdline[135]: //lib/dracut-lib.sh@25(strstr): '[' /dev/sdb1 '!=' /dev/sdb1 ']' [ 1.754241] hive dracut-cmdline[135]: //lib/dracut-crypt-lib.sh@12(crypttab_contains): read l d rest [ 1.754902] hive dracut-cmdline[135]: //lib/dracut-crypt-lib.sh@17(crypttab_contains): return 1
Try to replace /dev/sdb1 with the actual UUID in the crypttab and regenerate initramfs with -H
And you should append rd.luks.uuid= to the kernel command line. Otherwise systemd-cryptsetup-generator don't generate unit for you primary luks volume.
Created attachment 372742 [details] dracut boot logs with different parameter combinations After exchange the '/dev/sdb1' with the corresponding UUID in /etc/crypttab I've done several tests with several dracut versions: - 031-r1 (last version which works) - 034-r4 - 9999 (from aidecoe overlay) with and without '-H' parameter + with and without 'rd.luks.uuid' command parameter The only combinations which worked where: * 031-r1 with '-H' and with/without 'rd.luks.uuid' parameter * 031-r1 without '-H' and with 'rd.luks.uuid' parameter All other combination of different dracut versions and the different parameter combinations didn't work. The logs are in the attachment. P.S. 034 and 9999 are not able to show/handle plymouth splash ...
OK. It seems I get it now. 1. You have root on LVM, so you should add "rd.lvm.lv=vg_ssd/root" to the kernel cmdline. 2. Looks like you have swap on the second encrypted disk. And this is a problem, because dracut tries to activate this swap before mounting root. Given that I think dracut-9999 should work for you if you add "rd.lvm.lv=vg_ssd/root" to the kernel cmdline. If not, please attach the output of `lsblk` command.
(In reply to Alexander Tsoy from comment #18) > Given that I think dracut-9999 should work for you if you add > "rd.lvm.lv=vg_ssd/root" to the kernel cmdline. Hmm.. No. In your case dracut-9999 will also add swap device to the initqueue-finished. :( Probably the following commit broke things for you: http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=546d5dacf5d680526e3b2ddea757487c938a64c9
Try non-hostonly initramfs with "rd.luks.uuid=34deb499-56bd-47de-bf15-7b86278114a5 rd.lvm.lv=vg_ssd/root" in the kernel cmdline. Or try to revert commit from my previous comment.
(In reply to Alexander Tsoy from comment #18) > OK. It seems I get it now. > > 1. You have root on LVM, so you should add "rd.lvm.lv=vg_ssd/root" to the > kernel cmdline. > 2. Looks like you have swap on the second encrypted disk. And this is a > problem, because dracut tries to activate this swap before mounting root. > > Given that I think dracut-9999 should work for you if you add > "rd.lvm.lv=vg_ssd/root" to the kernel cmdline. If not, please attach the > output of `lsblk` command. At first, big Thanks for your help. With additional adding 'rd.lvm.lv=vg_ssd/root' the system boots now with dracut-999. There is no need to revert the mentioned commit. When building a initramfs without '-H' I get a warning of systemd: 'dracut-initqueue[272]: Warning: Unit file of systemd-cryptsetup@luks\x2d34deb499\x2d56bd\x2d47de\x2dbf15\x2d7b86278114a5.service changed on disk, 'systemctl daemon-reload' recommended.' It seems also, that the Plymouth binaries are not packed into the initrams, so the splash doesn't come up before I've to enter the passphrase.
(In reply to Mirko Guenther from comment #21) > With additional adding 'rd.lvm.lv=vg_ssd/root' the system boots now with > dracut-999. There is no need to revert the mentioned commit. Good. > When building a initramfs without '-H' I get a warning of systemd: > 'dracut-initqueue[272]: Warning: Unit file of > systemd-cryptsetup@luks\x2d34deb499\x2d56bd\x2d47de\x2dbf15\x2d7b86278114a5. > service changed on disk, 'systemctl daemon-reload' recommended.' And system doesn't boot at all? > It seems also, that the Plymouth binaries are not packed into the initrams, > so the splash doesn't come up before I've to enter the passphrase. If you will be the first person who open a separate bug for this issue, please also comment in bug 504018 or add its reporter to CC :) https://bugs.gentoo.org/show_bug.cgi?id=504018#c14
Is this still a problem in 036?
(In reply to Amadeusz Żołnowski from comment #23) > Is this still a problem in 036? No... works
Thanks. Closing.
