Description of problem: After update to kernel-2.6.27.9-159.fc10, initrd is prompting for password for encrypted filesystems even when key file is present. Version-Release number of selected component (if applicable): kernel-2.6.27.9-159.fc10 How reproducible: Every time. Steps to Reproduce: 1. Encrypt filesystems (cryptsetup), setup keys and update /etc/crypttab 2. Install kernel-2.6.27.9-159.fc10 3. Reboot Actual results: During boot, initrd prompts for "Password" for each encrypted filesystem. Expected results: Because keys are defined in /etc/crypttab, initrd shouldn't be prompting for password. Additional info:
This problem also exists with latest kernel-2.6.27.12-170.2.5.fc10 Big problem here. Anybody interested in addressing this??
Anybody investigating this in preparation for the next kernel release? As it is, I'm at least two kernel releases behind. I'm likely not the only one.
Problem still exists in kernel-2.6.27.15-170.2.24.fc10, forcing me now at least three kernel revs behind. C'mon Fedora - Anybody care about this?????
OK. The problem is this... When mkinitrd detects "swap" to be on an encrypted partition, it adds cryptsetup support and a line similar to the following to the "init" file in the initrd image. plymouth ask-for-password --command "cryptsetup luksOpen <swap device> <name>" Apparently, the mistaken assumption made by mkinitrd is that encrypted swap partitions will be always be password protected and doesn't take into account key file protection. Why does mkinitrd care about swap anyway??? Workaround is to temporarily comment out the swap partition in /etc/fstab and re-run mkinitrd immediately after kernel updates and before rebooting. Doing this creates a new initrd image that doesn't include the problematic cryptsetup stuff. Recommend removing cryptsetup and/or swap support entirely from mkinitrd until it can handle keyfile configurations.
kernel-2.6.27.19-170.2.35.fc10.i686, bug still there. :(
kernel-2.6.27.21-170.2.56.fc10.i686 Not fixed yet!!
Comment from Bugzapper Team =========================== Bug seems to contain all the required information to debug and fix. If some additional infomration is required, the assigned developer might request the creator of the bug 1. Changing the status from NEW to ASSIGNED 2. Reducing the seeverity and priority from "urgent" to "Medium" 3. 'cc'ing myself to the bug --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
kernel-2.6.27.24-170.2.68.fc10.i686 Still not fixed.
Also there in Fedora 11.
kernel-2.6.29.6-213.fc11.i586 / mkinitrd-6.0.87-1.fc11.i586 still prompts for password. Although, since Fedora 11, only the 'swap' partition prompts, whereas initially it prompted for every encrypted filesystem. I guess that's progress. :)
kernel-2.6.29.6-217.2.8.fc11.i586 mkinitrd-6.0.87-3.fc11.i586 No improvement. :(
kernel-2.6.30.8-64.fc11.i586 mkinitrd-6.0.87-4.fc11.i586 No change.
kernel-2.6.30.9-90.fc11.i586 Still broke.
kernel-2.6.30.9-96.fc11.i586 and nothing has changed. Just trying to keep this bug alive until it's resolved.
This is a mass edit of all mkinitrd bugs. Thanks for taking the time to file this bug report (and/or commenting on it). As you may have heard in Fedora 12 mkinitrd has been replaced by dracut. In Fedora 12 the mkinitrd package is still around as some programs depend on certain libraries it provides, but mkinitrd itself is no longer used. In Fedora 13 mkinitrd will be removed completely. This means that all work on initrd has stopped. Rather then keeping mkinitrd bugs open and giving false hope they might get fixed we are mass closing them, so as to clearly communicate that no more work will be done on mkinitrd. We apologize for any inconvenience this may cause. If you are using Fedora 11 and are experiencing a mkinitrd bug you cannot work around, please upgrade to Fedora 12. If you experience problems with the initrd in Fedora 12, please file a bug against dracut.