[arch-releng] dm-crypt

Dieter Plaetinck dieter at plaetinck.be
Mon Apr 12 07:14:39 EDT 2010


On Sun, 11 Apr 2010 17:17:25 -0500
Chris Brannon <cmbrannon79 at gmail.com> wrote:

> Dieter Plaetinck wrote:
> > 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.
> 
> That's where I called stat, and there were no other
> filesystems processed in between those two.
> Could udev be doing something in between those two calls?
> I'm grasping at straws again.
> 
> > 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. 
> 
> Ok, here's what I get
> from file, ls -al, and stat on /dev/mapper/cryptoroot.  I called them
> manually right after the failure.
> 
> /dev/mapper/cryptoroot: symbolic link to `../dm-0'
> lrwxrwxrwx 1 root root 7 Apr 11 22:09 /dev/mapper/cryptoroot
> -> ../dm-0 File: `/dev/mapper/cryptoroot' -> `../dm-0'
>   Size: 7         	Blocks: 0          IO Block: 4096
> symbolic link Device: eh/14d	Inode: 5239        Links: 1
> Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/
> root) Access: 2010-04-11 22:09:25.043276999 +0000
> Modify: 2010-04-11 22:09:13.903282148 +0000
> Change: 2010-04-11 22:09:13.903282148 +0000
> 
> -- Chris

I'm stumped.
this looks fine.
maybe there's a timing thing? maybe the devicefiles change just after aif dies.

how about this:
aif -p interactive ; ls -alh /dev/mapper; file /dev/mapper/*; stat /dev/mapper*; \
sleep 10; ls -alh /dev/mapper; file /dev/mapper/*; stat /dev/mapper*; 



Dieter


More information about the arch-releng mailing list