[arch-releng] 2010.04.05 snapshots ready for testing

Dieter Plaetinck dieter at plaetinck.be
Sun Apr 11 06:23:03 EDT 2010

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

> Dieter Plaetinck wrote:
> > can you maybe do an ls -alh, stat, and file on $1 as the first
> > thing in process_filesystem?
> *SNIP*
> > 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.
> Ok, I added file, ls -al, and stat at both points.
> It worked like a charm, even when aif is invoked
> as aif -p interactive.
> That log is the first attachment.
> Next, I removed the file and ls -al calls, so we were left with only
> the two stats.
> I wanted to make it fail again, but it didn't oblige.

odd. byebye "it works with -d, but always fails without it" theory.
this makes me think again that simple things like writing to a file do
something with filedescriptors that affect the breakage behavior.

> That log is the second attachment, partlog2.txt.
> The stat following cryptsetup is different than the stat at the start
> of process_filesystem.  In the first stat, you'll see
> that /dev/mapper/cryptoroot is a block device.  It is at inode 7872.
> The second stat shows that /dev/mapper/cryptoroot is a symlink, and it
> is at inode 7949.
> -- Chris

so, those two process_filesystem invocations follow each other directly
right? it's not that it did some other filesystems in between but you
left those out? and your stat calls are just after cryptsetup luksOpen
and just at the beginning of process_filesystem? because really nothing
should happen between those two that would affect
what /dev/mapper/cryptoroot is. There is some labelling,mounting,
adding to fstab logic but it should all be skipped
for /dev/mapper/cryptoroot.

You could put stat calls all over process_filesystem and
process_filesystems, to find out where exactly it changes.

but then again, as you said adding those calls makes it not break...
maybe you should start with a clean aif again, make it fail and then
manually do file, ls etc on /dev/mapper/cryptoroot.
because the initial problem was that aif breaks on a simple `[ -z "$1"
-o ! -b "$1" ]` check. 


More information about the arch-releng mailing list