Description of problem: I am seeing failure on some boots (maybe %50) where when it gets to the point where it needs to unlock addition file systems (e.g. /home), there is a long pause (maybe a minute) and then when the boot continues there are a lot of failures because the file systems haven't been unlocked. When there is no pause, things work as expected. These addition file systems use the same passphrase as the root filesystem. Version-Release number of selected component (if applicable): systemd-20-1.fc15.i686 How reproducible: Something on the order of 50%. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Some discussion in bug 678927 has talked about this issue as well. I am not sure this is really a beta blocker because there is an easy work around. (The probability of success is high enough that it only takes a couple of reboots on average to get a good one.) I would think this is a nice to have for beta in any case.
Starting yesterday morning one of my machines starting having this failure on every boot (or I have become very unlucky). That machine has /var on a separate partition and I have reverted rsyslog. I'll be testing this some more tonight to see if there is any change with further updates.
This morning the machine is mounting encrypted devices during the boot process again. (I don't know that the random failures are fixed, just that at least once it booted OK.)
It seems to be back to about %50 again. After trying to reboot again this moring it took a few tries to get past mounting additional encrypted file systems.
*** This bug has been marked as a duplicate of bug 678927 ***