> Date: Fri, 29 Mar 2013 05:32:50 -0400
> From: "Cliff McDiarmid" <cliffhan...@gardener.com>
> To: "akhiezer" <lf...@cruziero.com>,
> "BLFS Support List"
> <blfs-support@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
--
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
