[blfs-support] Autofs problem on LFS7.2

akhiezer lfs65 at cruziero.com
Fri Mar 29 03:07:22 PDT 2013


> Date: Fri, 29 Mar 2013 05:32:50 -0400
> From: "Cliff McDiarmid" <cliffhanger at gardener.com>
> To: "akhiezer" <lfs65 at cruziero.com>,
>         "BLFS Support List"
> 	<blfs-support at linuxfromscratch.org>
> Subject: Re: [blfs-support] Autofs problem on LFS7.2
>
	.
	.
> > > > > > > Right.  I've recompiled autofs(had to include MIT Kerberos)and the results were intially promising.
> > .
> > .
> > > > > You may be right about Kerbos, I seem to remember getting round that originally and not compiling against it.
> > 
> > 
> > Might come back to: why 'had to include MIT Kerberos' for that second compile, 
> > yet not for the first one; and for the first compile what did 'getting round' 
> > (ie avoiding) compiling kerberos entail.
> > 
> > 
> > > > OK: so at this stage I'd recompile the 'patch-reverted' autofs-5.0.7 - i.e. use 
> > > > the version where you have got that 'LIBTIRPC' block of code commented-out - and 
> > > > follow the same steps as you did originally, but for the './configure ...' 
> > > > cmdline _add_ the '--without-hesiod' option.
> > >
> > > I've now recompiled 'patch-reverted' autofs-5.0.7 without MIT Kerberos.  Sadly this has made no difference.
> > > When I plug in the usbstick the 'testautomount' dir. is created, but not 'sandisk'.
> > >
> > .
> > .
> > > When the usbstick is plugged, autofs spits the following again:
> > >
> > > handle_packet: type = 3
> > > handle_packet_missing_indirect: token 1, name sandisk, request pid 1997
> > > attempting to mount entry /testautomount/sandisk
> > > lookup_mount: lookup(program): looking up sandisk
> > > lookup(program): lookup for sandisk failed
> > 
> > 
> > It's doing 'lookup(program)' there, instead of 'lookup(file)': tracing through 
> > the src indicates that one way that this can happen under certain 
> > circumstances/conditions is if e.g. a map file has execute permission set. 
> > Have you got any execute permissions set on either of the map files? What does 
> > the following show currently:
> $ \ls -laF /etc/auto.master /etc/auto.testautomount
> -rw-r--r-- 1 root root 171 Mar  9 18:06 /etc/auto.master
> -rwxr-xr-x 1 root root  43 Mar 25 21:08 /etc/auto.testautomount*
> $


I'd do (and verify):
$ chmod 644 /etc/auto.testautomount

It's only the likes of /etc/auto.net and /etc/auto.smb that need to be executable, 
per the notes at the top of those files.


> > 
> > 
> > Can you also post the current complete contents (don't omit any empty or commented 
> > lines) of the maps - reason is that I was able to 'break' automount in various 
> > ways with mildly-subtle (deliberate-)'oversights' in the map files:
> $ cat -A /etc/auto.master /etc/auto.testautomount
> # Begin /etc/auto.master$
> $
> #/media/auto/sandisk  /etc/auto.misc  --ghost$
> $
> /testautomount      /etc/auto.testautomount$


Change this to:
/testautomount      file:/etc/auto.testautomount

This is to try to nail-down automount to interpreting the map as a file rather 
than leaving automount to make its own estimation - and possibly mis-guessing 
it to be a program.

If that still doesn't work then change it to:
/testautomount      file,sun:/etc/auto.testautomount

This should further restrict automount's leeway for making an incorrect 'guess' 
as to the type of map that '/etc/auto.testautomount' is.


> $
> #/home        /etc/auto.home$
> $
> # End /etc/auto.master$
> $
> $
> sandisk     -fstype=ext2     :/dev/sdb$
> $
> $
> $


Looks ok.


> > 
> > 
> > > dev_ioctl_send_fail: token = 1
> > > failed to mount /testautomount/sandisk
> > > st_expire: state 1 path /testautomount
> > > expire_proc: exp_proc = 3063610176 path /testautomount
> > > expire_cleanup: got thid 3063610176 path /testautomount stat 0
> > > expire_cleanup: sigchld: exp 3063610176 finished, switching from 2 to 1
> > > st_ready: st_ready(): state = 2 path /testautomount
> > > st_expire: state 1 path /testautomount
> > > expire_proc: exp_proc = 3063610176 path /testautomount
> > > expire_cleanup: got thid 3063610176 path /testautomount stat 0
> > > expire_cleanup: sigchld: exp 3063610176 finished, switching from 2 to 1
> > > st_ready: st_ready(): state = 2 path /testautomount
> > >
> > > > At this stage, I'd say you don't need to uninstall kerberos: but I'd suggest 
> > > > ensuring it is not running; stop it via '/etc/rc.d/init.d/krb5 stop' (or similar) 
> > > > and verify via ps that none of its components are running, and stop them if they 
> > > > are; it may be useful if necessary to refer to the list of programs in the 
> > > > 'Short Descriptions' section at the foot of the page 
> > > > 'http://www.linuxfromscratch.org/blfs/view/svn/postlfs/mitkrb.html', as a 
> > > > guide/checklist.
> > > > 
> > 
> > 
> > If still no-go, then I'd do:
> > ----
> > (1) Go back to the original src - i.e. where that 'LIBTIRPC' block is _NOT_ 
> >  commented out - and compile as in the book, but for the configure stage, do:
> > 
> >  ./configure --prefix=/ --mandir=/usr/share/man \
> > --without-systemd --without-libtirpc --without-hesiod \
> > --without-openldap --without-sasl
> > 
> >  (The sasl, ldap, hesiod, &c stuff can be added back in later once we have got 
> >  a working autofs from a basic config).
> >  Then test and see if it goes OK.
> >  Post the output from 'automount -v -f -d /etc/auto.master' , incl showing what 
> >  happens when you plug a stick in: just copy'n'paste the full session, please.
> > --
> > (2) If still no-go after '(1)', then do the same as '(1)' but with the 
> >  'patch-reverted' src - i.e. with that 'LIBTIRPC' block commented out - and 
> >  use the same 'configure ...' line as in '(1)' .
> > ----
>
> Many thanks, will wait to see what you think of the above before moving on to the above.
>
> MAC


Leave the above context present in next few replies or so, for ref - thanks.


rgds,
akh





--



More information about the blfs-support mailing list