On Sun, 11 Apr 2010 17:17:25 -0500
Chris Brannon
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