On Wed, 2010-03-31 at 02:02 +0000, Steve Langasek wrote: > TJ, > > It's an important distinction that the original bug submitter's keyfiles > are listed as being located on /etc, whereas yours are on an external > USB device. If your keys aren't on the root device, then yes, > decrypting the devices is not going to work reliably at boot because > there's no way for the cryptdisks-udev job to know it's supposed to wait > for this other device to be mounted.
Thanks for giving me a clue on where to investigate, Steve. That doesn't sound quite right to me. cryptsetup 'knows' (or should know) that for each device it must run the keyscript. That keyscript then deals with ensuring the kernel drivers are loaded, the device has settled, and then mounts the device in order to access the key-file - in other words, it is the keyscript's responsibility to 'wait for this other device to be mounted', not cryptdiskd-udev. Also, it has to be remembered that the encrypted root file-system was successfully unlocked from the same key-file on the external device using the same keyscript, so we know that the device is accessible and therefore the keyscript will note that and immediately do the mount. Is there a way to have the cryptsetup jobs generate a log similar to mountall to help figure out what is actually happening? I'm at the wrong end of a 20 hour session right now so not thinking as incisively as I might be. I'll come at it fresh tomorrow and see what I can discover and report back. One thing I'll try is having the key-file on the root file-system just to see if that is the differentiator. -- lucid: Failure to bring up cryptsetup devices by key files (when not using "splash") https://bugs.launchpad.net/bugs/532898 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
