Description of problem: if use dracut-054 make img.when the system start, can't auto unlock luks partition that using keyfile specified by rd.luks.key Version-Release number of selected component (if applicable): 054-6.git20210518.fc34.{AARCH64,X86_64} How reproducible: Steps to Reproduce: 1.make a keyfile use dd if=/dev/urandom of=./keyfile bs=1 count=### 2.format a luks partition cryptsetup luksFormat /dev/#### ./keyfile 3.install F34 on it 4.login F34 upgrade dracut to ver054 && edit /etc/crypttab add keyfile path 5.touch & edit /etc/dracut.conf.d/99-auto-boot.conf add 'omit_dracutmodules+=" systemd "' 6.copy keyfile in uDisk 7.edit /etc/default/grub add "rd.luks.key=/keyfile:UUID=<uDisk(partition) UUID>" 8.dracut -fv 9.grub2-mkconfig -o <grub config file path,E.g: /etc/grub2-efi.cfg> 10.reboot Actual results: log say: cryptsetup : unknown action and Require use Password unlock partition Expected results: on system startup kernel auto read keyfile unlock luks partition then system wait user login Additional info: when dracut 053-4.f34 everything is normal. --------------------------------- dnf downgrade dracut -y dracut -fv reboot --------------------------------- system can auto startup in dracut 054-6.git20210518.fc34 /usr/lib/dracut/modules.d/90crypt/cryptroot-ask.sh line 168 change cryptsetup -d - "$cryptsetupopts" luksOpen ...... to cryptsetup -d - $cryptsetupopts luksOpen ...... then run cmd: dracut -fv reboot system don't need input Password,can satrtup automatically
Is this related to https://old.reddit.com/r/Fedora/comments/nkjxls/512_kernel_broken/ ? I have a similar issue with 054-12.git20210521.fc34 which caused my system not to boot with 5.12er kernels as described in the reddit post. If you need logs or any further information, I can provide them. Just tell me, what you need.
(In reply to Niklas Fischer from comment #1) > Is this related to > https://old.reddit.com/r/Fedora/comments/nkjxls/512_kernel_broken/ ? Seeing the same behavior with dracut-054-12.git20210521.fc34. When the initrd is build with this version the system won't boot. It hangs Switching Root ... and later dbus-broker.service is failing and all associated services. Setting SELinux to permissive mode solves the problem and the system will eventually boot (still take a long time but at least dbus-broker and all associated services are starting). When downgrading to dracut-053-4.fc34.x86_64 and rebuilding the initrd for the specific kernel, boot works again and there are also no SELinux issues reported.
We have the same problem, described here: https://github.com/dracutdevs/dracut/issues/1521 It seems that the bluetooth service does not stop gracefully and everything after goes downhill. When omiting the bluetooth modules from the initramfs it boots fine. --- Description: as soon as I pair my Bluetooth devices and regenerate the initramfs it does not boot anymore hanging at Starting... Switch Root Setup: LUKS encrypted system dracut 054-12.git20210521.fc34 systemd Expected behavior: boot process should be successful Bluetooth devices: lspci: 02:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a) lsusb: Bus 003 Device 003: ID 8087:0029 Intel Corp. AX200 Bluetooth Thinkpad BT keyboard with trackpoint Logitech MX Master mouse Workaround: as soon as I omit the bluetooth module from dracut and regenerate the initramfs the boot process succeeds
Same with dracut-055-2.fc33.x86_64 (and gpged key file). Changing cryptsetup -d - "$cryptsetupopts" luksOpen ...... to cryptsetup -d - $cryptsetupopts luksOpen ...... in file /usr/lib/dracut/modules.d/90crypt/cryptroot-ask.sh and line 168 helps as well.
Same here with dracut-055-2.fc33.x86_64, system asks for a password on boot instead of using provided keyfile. Removing the quotes around $cryptsetupopts fixes it. In my case, $cryptsetupopts is an empty var
I confirm that the workaround of line 168 (see above) of /usr/lib/dracut/modules.d/90crypt/cryptroot-ask.sh works on my fedora34
Same problem here on both fedora 33 and fedora 34 systems, and can confirm that the removal of the quotes also worked for me. As far as I can see the script as it stands will never work when cryptsetup supports --allow-discards (as in reports it in it's help), since if cryptsetupopts is empty you'll get " --discard-opts" with a leading space, and if it's not empty you'll get "--you-crypt-setup-opts --allow-discards" all as one argument. From what I can see the only case where it would work with the current quoting is when cryptsetupopts is a single option, with no value argument and --allow-disards isn't supported?
Seems to have been fixed upstream? https://github.com/dracutdevs/dracut/issues/1528
Any chance of getting the upstream fix merged? this is still broken in fedora 35 (dracut-055-6.fc35.x86_64) and the patch from https://github.com/dracutdevs/dracut/issues/1528 has resolved the issue on fedora 33, 34 and 35 for us.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.