[arch-releng] 2010.04.05 snapshots ready for testing

Dieter Plaetinck dieter at plaetinck.be
Sat Apr 10 16:40:26 EDT 2010

On Sat, 10 Apr 2010 15:13:18 -0500
Chris Brannon <cmbrannon79 at 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

> 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.


More information about the arch-releng mailing list