You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Upon creating a cryptoLUKS partition, the system will no longer boot unless I correctly enter the passphrase for the cryptoLUKS device. The mere existence of this partition causes this to happen. There is no rd.luks boot parameter. No entry in /etc/crypttab.
Distribution used
Fedora 34
Dracut version
dracut-053-5.fc34.x86_64
Init system
systemd-248-2.fc34.x86_64
To Reproduce
Install a Fedora system without any encryption. It boots and starts up as expected.
Add a partition and use 'cryptsetup luksFormat' on it. No other changes.
Boot the system. Now it waits indefinitely for a passphrase.
Expected behavior
The system should still startup without requiring intervention from the user.
Additional context
The problem doesn't happen following downgrade to dracut-051-1.fc34.x86_64 and rebuilding initramfs. journal.log
The text was updated successfully, but these errors were encountered:
OK after downgrading to dracut-051, rebuilding initramfs and showing the problem doesn't reproduce; I upgraded back to 053, rebuilt the initramfs and expect it to happen again. It doesn't. I don't know why because the initramfs clearly contains systemd-248-2 and dracut-053-5 in both cases. I'm not sure what's different.
In the reported failing journal.log I first see this device's UUID:
[ 1.923539] systemd[1]: unit_file_build_name_map: normal unit file: /run/systemd/generator/systemd-cryptsetup@luks\x2dafd5a880\x2d6672\x2d4d63\x2d913e\x2dd6b6d2825d98.service
This line doesn't exist anymore. Attaching that as journal2.log. journal2.log
Describe the bug
Upon creating a cryptoLUKS partition, the system will no longer boot unless I correctly enter the passphrase for the cryptoLUKS device. The mere existence of this partition causes this to happen. There is no rd.luks boot parameter. No entry in /etc/crypttab.
Distribution used
Fedora 34
Dracut version
dracut-053-5.fc34.x86_64
Init system
systemd-248-2.fc34.x86_64
To Reproduce
Expected behavior
The system should still startup without requiring intervention from the user.
Additional context
The problem doesn't happen following downgrade to dracut-051-1.fc34.x86_64 and rebuilding initramfs.
journal.log
The text was updated successfully, but these errors were encountered: