[arch-releng] 2010.04.05 snapshots ready for testing

[Dieter Plaetinck]

On Sat, 10 Apr 2010 13:27:17 -0500
Chris Brannon <cmbrannon79 at gmail.com> wrote:

> > well, crap. if the problem occurs only when not doing logging, then
> > this is going to be a bitch to investigate. (did you try just just
> > '-l' or just '-d' instead of '-l -d' ?)
> 
> It also fails with -l (no -d), though the log file isn't too helpful.

> It always succeeds with -d, regardless of whether -l is present.
you could run aif -p interactive  -l and change relevant debug calls
(eg those in process_filesystem) to log calls.

> I wonder whether die_error is actually dying when debugging is
> enabled?
it definitely should. why do you doubt this? (you see that aif exists, after spawning the error,
right?).
you see. try -l then

> 
> AFAIK, here is the line in the AIF code that is failing:
> 	[ "$2" != lvm-lv ] && [ -z "$1" -o ! -b "$1" ] && die_error
> "process_filesystem needs a partition as \$1" # Don't do this for
> lv's.  It's a hack to workaround non-existence of VG device files.
> It's line 692 of src/core/libs/lib-blockdevices-filesystems.sh in my
> (up-to-date) clone.
> 
> The -b $1 caught my attention.  Is it possible that this is failing?
> My /dev/mapper/cryptoroot is a symlink to another device
> (/dev/dm-0, IIRC), and that is a block device.

the fact that it's a symlink, is by itself not a problem:
example:

$ ls -alh /dev/mapper/cryptpool-home
lrwxrwxrwx 1 root root 7 Apr 10 08:28 /dev/mapper/cryptpool-home -> ../dm-3
$ [ -b /dev/mapper/cryptpool-home ]
$ echo $?
0

we first of all must be sure that $1 is what we expect. so put a log call as the very fist thing
in process_filesystem that logs "$@"

> I wonder if that block device somehow didn't become available
> soon enough for process_filesystems /dev/mapper/cryptoroot ext4 to use
> it?  I'm running this in a VM after all.

it should. process_filesystems is designed to do them in correct order (this is
why it's very useful to change the debug calls to log calls, then you can follow which devices it does)
each process_filesystem call is definitely synchronous btw. ie. the function runs as long as the mkfs/cryptsetup/.. is running.
once cryptsetup 
> 
> PS.  I'm mainly testing this because you said that you'd like for
> folks to test the exotic features.

thank you. this is definitely needed.