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
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*;
More information about the arch-releng