[275] in SIPB_Linux_Development
Quiche developments for the day
daemon@ATHENA.MIT.EDU (ghudson@MIT.EDU)
Tue Dec 14 21:27:04 1993
From: ghudson@MIT.EDU
Date: Tue, 14 Dec 93 21:26:22 EST
To: linux-dev@MIT.EDU
I opened up quiche, made sure the 5 1/4" drive was plugged in
properly, and made sure the BIOS was configured properly. Still
doesn't work.
I set up quiche to export /usr/src read-only, restricted to *.mit.edu
and *.ee.tufts.edu (because I told Alex Jones he could mount it).
quiche still doesn't understand uid maps. Although
quiche:/usr/src/athena is on a separate partition, I can access it
just fine after NFS-mounting /usr/src. We should probably ask for a
hesiod pointer for "sal" to quiche:/usr/src at this point.
This (from nfsd.8) explains why we don't have to export two separate
partitions:
nfsd starts a daemon that handles client filesystem
requests. Unlike nfsd on some other systems, nfsd oper-
ates as a normal user-level process. The server also dif-
fers from other nfsd implementations in that it mounts an
entire file hierarchy not limited by the boundaries of
physical file-systems. The implementation allows the
clients read-only or read-write access to the file hierar-
chy of the server machine.
We're also running "rpc.ugidd". I had no idea what this is, and the
man page was corrupt. I ftp'd the sources (/usr/adm/packages/*.desc
is really neat) and restored the man page. We were also missing the
man pages for nfsd and mountd and probably exports, so I copied those
in. I also noticed that we were missing some of the rpc man pages
(the 3n and 8c pages), so I copied those in. More fodder for
~/tmp/debian.notes. At any rate, ugidd turns out to be a service for
NFS mappings, but I still get from attach:
attach: Warning: mount daemon on QUICHE-LORRAINE.MIT.EDU doesn't understand UID maps
(filesystem quiche:/usr/src)
(The attach still succeeds on a sun.) I'm not sure how to get ugidd
to work; the man page isn't all that helpful.
mwm is looking for its libraries in /lib. Who can relink it? Also, I
found a symlink in /lib to libX11.a; please don't make symlinks like
this, because they will just mask problems that other Linux users are
going to have if we don't re-link programs in lockers. I think
because the new libraries use ld.so, the locations shouldn't matter
once we re-link everything, although I'm not sure of this. At any
rate, X libraries are to be found in /usr/lib henceforth.
I made a list of programs in the sipb and outland lockers which break
looking for their libraries in /lib: xvile, xmosaic, xneko, oneko,
xrn, betaxrn, xgopher, xdla. xpanic and xzwrite also break for
different reasons.
Here's the result of my attempt to relink and reinstall these
programs:
xvile: link failed on unresolved symbol _setcursor
xrn: build tree doesn't exist (see betaxrn)
betaxrn: successful
xneko: successful
oneko: successful
xmosaic: successful
xgopher: couldn't find a build tree
xdla: couldn't find a build tree
That leaves xvile, xrn, xgopher, and xdla broken.
Apparently, the aklog warning message is sent from the translator
machine (e.g. ni) through an AXN_OP_STDERR request. Not much chance
of getting rid of that, unfortunately.
I commented out the /usr/sbin/accton calls in /etc/rc.d/rc.K and
/sbin/brc (the program that gets run on shutdown), since we don't do
accounting.
--GBH
