On Sun, 2008-07-13 at 08:52 +0200, Vitezslav Kotrla wrote: > > I suspect that this is actually #467200. Briefly, race conditions mean > > that HAL will only sometimes be able to mount encrypted partitions. > > Please note that encrypted _partitions_ (e.g. /dev/sde1) are mounted > _every_ time on my system.
This is entirely possible--it's the nature of race conditions. About a year ago I didn't even know this bug existed--then six months ago, I stopped being able to mount encrypted volumes at all. > It's LUKS volume spanning the _whole_ device (e.g. /dev/sde) that is > _not_ mounted (but opened successfuly anyway). But maybe this could be > result of race conditions described in #467200? What exactly should I > try to verify this issue? After attaching a device, entering your passphrase when prompted, and observing that it has not been mounted, run 'lshal' and attach the output to this bug report. We're looking for encrypted volumes that HAL thinks are of size 0. This happens because when cryptsetup is run, it creates a mapping called 'temporary-cryptsetup-$randomstuff', presumably in order to test that the mapping worked correctly. HAL sees this and tries to read it to add it to the device tree; but before this is finished, cryptsetup removes the mapping and replaces it with the final mapping of the correct name. This confuses HAL and it never gets around to aborting its probe of the temporary device, nor probing the new, final device. And so you end up with a decrypted volume of size 0 in the device tree. -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078
signature.asc
Description: This is a digitally signed message part
