is NFS mounting borked in bb-1.1.1?

Kumar Gala galak at kernel.crashing.org
Wed Mar 29 19:32:34 UTC 2006


On Mar 29, 2006, at 1:23 PM, Rob Landley wrote:

> On Wednesday 29 March 2006 12:24 pm, Kumar Gala wrote:
>> However, this is a secondary issue with parsing of /etc/fstab that
>> still exists for nfs mounts.  I'm confused about what the following
>> is trying to do:
>
> When you have one argument, it tries to figure out which fstab  
> entry that
> refers to.  It could be the device, it could be the directory, or  
> it could be
> a relative path pointing to either.
>
> The remembering the entry bit is more for remount than mount, it's  
> so if
> somebody overmounts the same directory with a second filesystem, we  
> match the
> most recent mount (which is the visible one).
>
>> The issue is I have an fstab that looks like:
>>
>> proc            /proc           proc
>> defaults                        0 0
>> none            /dev/pts        devpts
>> defaults                        0 0
>> sysfs           /sys            sysfs
>> defaults                        0 0
>> tmpfs           /tmp            tmpfs
>> defaults                        0 0
>> kgala_lnx:/local /local nfs defaults,nolock 0 0
>>
>> then I do the following on the command line:
>>
>> # mount /local
>> mount: Mounting  on /local failed: Invalid argument
>
> Huh.  Parsing the above, it looks like it should do a:
>
>   mount -t nfs -o defaults,nolock kgala_lnx:/local /local
>
> Does that work?

Yes that works.

>
>> We should probably only match on mtcur->mnt_dir if mtcur->type ==
>> "nfs"
>
> Even if you didn't say noauto?

Well, I'd assume we would still do the MOUNT_NOAUTO | MOUNT_SWAP  
testing.

>> , however I dont see how we would actual call singlemount() even
>> if we matched the mtcur.
>
> mntgetent_r() populates a structure from fstab.  We keep two  
> structures: the
> current one we're looking at and the last one we found.  That's the  
> swapping
> mtcur and mtnext part, they both point to mtpair.  At the start of  
> the loop,
> mtnext is pointed at whichever one mtcur doesn't point to.  When we  
> load an
> mtcur we want to keep, we point mtcur at mtnext so the next load will
> overwrite the other one.
>
> When we hit the end of the list we look at the last match (which is  
> in mtnext,
> the one we _didn't_ load.)
>
> I was calling mtnext "mtother" for a while, but it was  
> approximately as
> confusing either way.  mtswap, perhaps?

But we dont do anything with mtnext which is my confusion.  I believe  
what's happening in my case is we iterate over all entries in /etc/ 
fstab dont find a match and fall through to the end of the file rc=1  
so I get the "Mounting ... failed" error.

The only way we mount anything is if optind == argc.  In my case  
optind = 1 and argc = 2.  Thus no mater what matching occurs we  
aren't going to mount anything.

- kumar




More information about the busybox mailing list