rogerj@batcomputer.tn.cornell.edu (Roger Jagoda) (10/11/89)
Folks,
I have received the following error more than once. Could someone
with source (at NeXT, Avie?) please give me a clue as to what the
problem is. The unusual thing here is, that we run almost 30 machines
diskless with the same programming and this only happens on 1 machine!
First the error:
remote private filesystem on schuyler:/clients/montour@/private
nfs_getremotevfs: remote mount error=13
nfs_mountroot:can't get root file handle
panic (cpu0) root mount, cannot mount root
panic
And then the machine freezes up and must be rebooted. Now, schuyler is
the server (a 660 MB disk machine), the client runs diskless (as do six
other clients). They find their directory trees on schuyler (made by
newclient script) and do all their disk mounts via nfs (hence the source
of the error message). The important files are /etc/exports,
/etc/bootptab (niloaded into "/", /etc/bootparams (niloaded into "/").
They are below:
exports:
/ -root=tompkins:upson:cayuga:seneca
/clients/montour -access=montour,root=montour
/clients/reading -access=reading,root=reading
/clients/bradford -access=bradford,root=bradford
(there are three other lines for the three other diskless clients off
the server)
bootptab:
host htype haddr iaddr bootfile
montour 1 00:00:0f:00:0a:3b 128.84.207.41 mach
reading 1 00:00:0f:00:08:b6 128.84.207.46 mach
(more lines for the other clients)
bootparams:
montour root=schuyler:/ \
private=schuyler:/clients/montour@/private
reading root=schuyler:/ \
private=schuyler:/clients/reading@/private
(more lines for other clients)
More info:
niutil -read / /machines/montour reports:
name: montour
ip_address: 128.84.207.41
en_address: 0:0:f:0:a:3b
bootfile: mach
bootparams: private=schuyler:/clients/montour@/private root=schuyler:/
serves: montour/local
The same thing reports for all the other diskless clients off schuyler.
The weird thing is, the entire facility is run diskless (30 clients off
6 servers) and we only get this problem with one machine, well, actually
we get this problem a lot, but since we re-made the lab over we haven't
had the problem again until now (remade means skragg all the server
drives and re-install. There was a severe bug involved with bootparams
and netinfo forcing the configurer to go into NetManager, open the host
entry, make any small change, and re-save the entry).
Well, just in case I tried this anyway...no luck. So, if anyone has
source and could point me in the right direction, I'd be greatful.
Moreover, how does one obtain source for MACH or the TCP-IP portions or
NFS services, etc. I had heard 1.0 sources were being shipped with the
distribution but I can't find them. Thanks in advance for any help.
Roger Jagoda
System Analyst
Cornell University
Internet: FQOJ@CORNELLA.CIT.CORNELL.EDU
Bitnet: FQOJ@CORNELLA.BITNET
Snail Mail: 220 Cornell Comp. Cent. Cornell University, Ithaca, NY 14853
AT&T: (607) 255-8960 rogerj@batcomputer.tn.cornell.edu (Roger Jagoda) (10/15/89)
>I have received the following error more than once. Could someone >with source (at NeXT, Avie?) please give me a clue as to what the >problem is. > Avie has once again come through, thanks. Actually, the error seems to coincide with standard unix errors in sys/errno.h which I didn't know (sourced from Avie again!). Error 13 is EACCES or permission denied. This meant that the server was not allowing root access to the client. Avie suspected the exports file and he was right. The error: >nfs_getremotevfs: remote mount error=13 >nfs_mountroot:can't get root file handle >panic (cpu0) root mount, cannot mount root /etc/exports: >/ -root=tompkins:upson:cayuga:seneca >/clients/montour -access= montour,root=montour >/clients/reading -access=reading,root=reading >/clients/bradford -access=bradford,root=bradford > That space after "access= " was enough to do it. Examination of /etc/xtab showed the following: / -root=seneca:cayuga:upson:tompkins: /clients/montour -access= access=odessa, root=montour ....<other client lines> So you see the problem. The server was exporting the file- system fine, but not with the proper accesses. Correcting /etc/exports, then re-exporting (exportfs -va) solved the problem. Perhaps this is reason (small mistakes in flat files causing BIG trouble over networks) to incorporate the exports file into NetInfo somehow (Peter, Avie, any ideas?). Before everyone starts lining up to flame or support please don't. We've hashed this one fairly thoroughly. Those who've used NetInfo either like it or not and I certainly agree with everyone's reasons for both. But let me say this, for NON-unix gurus (I'm a converted NetWare SysOp myself), the flat files are just a pain. NetInfo, for all its problems will be a panacea for those NOT having a year of UNIX administration behind them. All the bootpara info, and mounting info is already in netinfo, it seems like exports should also be (something like niload -v exports . </etc/exports.local...we already do this for fstab.local and fstab.network). Thanks to all who responded for helping, I hope the resolution is equally useful. >Roger Jagoda >System Analyst >Cornell University >Internet: FQOJ@CORNELLA.CIT.CORNELL.EDU >Bitnet: FQOJ@CORNELLA.BITNET >Snail Mail: 220 Cornell Comp. Cent. Cornell University, Ithaca, NY 14853 >AT&T: (607) 255-8960