On Sat, 10 Apr 2010 15:13:18 -0500 Chris Brannon <cmbrannon79@gmail.com> wrote:
if you can reproduce it consistently, file a bug report. however i cannot make guarantees as to when it will be fixed, due to time constraints. I can assist you if you want to debug this issue yourself, though.
I added some debugging statements to the AIF code on the CD image, and what I found is even more baffling. When process_filesystem /dev/mapper/cryptoroot ext4 is called, the test [ ! -b $1 ] returns 0 at the top of the function.
okay. so you are sure now that process_filesystem is called with args '/dev/mapper/cryptoroot' and 'ext4'. can you maybe do an ls -alh, stat, and file on $1 as the first thing in process_filesystem?
However, the test [ -b /dev/mapper/$fs_label ] returns 0 right after cryptsetup format and cryptsetup open have been called.
that's really odd. so basically you are saying when the dm_crypt is created -b on it returns true, but a bit later -b on the same thing does not. please doublecheck that $fs_label is cryptoroot here. do a ls -alh, stat and file here also. so we can compare.
The bizarre part is that everything works when I use the -d option for debugging output. I'm beginning to wonder if qemu isn't the source of the trouble, but I don't have a spare machine for testing.
I think it probably has something to do with open fd's such as stdin/stderr etc. notice that we do some magic in process_filesystem like cryptsetup $fs_params $opts luksFormat -q $part >$LOG 2>&1 < /dev/tty ; ret=$? #hack to give cryptsetup the approriate stdin. keep in mind we're in a loop (see process_filesystems where something else is on stdin) infofy "Please enter your passphrase to unlock the device" cryptsetup luksOpen $part $fs_label >$LOG 2>&1 < /dev/tty; ret=$? || ( show_warning 'cryptsetup' "Error luksOpening $part on /dev/mapper/$fs_label" ) ;; maybe the debugging somehow affects this. Dieter