The final saga.  NFS/kernel-build/fsck is dead.  Long live NetBSD.
It's all up and firing.  For anyone who's interested, here's the
lowdown <and bear in mind I've not downloaded anything new from the
Net>.  <Apologies for folks who've seen this before, but it might be
useful for a future FAQ>


If you're using MeetingPearls2, don't use the almost-generic kernel
<with ISO9660 and ethernet support> and expect NFS to work.  For some
reason, the RPC portmapping got forgotten in the kernel, which means
you get mounts but no I/O.  Like, useful, folks.  I spotted it when
playing about with /etc/rc and /etc/netstart, and engaged portmapd as
well as the expected mountd and nfsiod, and it threw up errors.  I
also think that particular kernel wasn't actually a proper 1.0, which
would explain all the following...


Kernel rebuilding part 1: "What the f*ck????"

Under pure 1.0 from the CD, I couldn't get a fresh pared-down build
to work at all until I hit the config file with a friendly Unix god
and stripped the networking options in the config file to

options        INET                    # IP networking support (Required)
options         GATEWAY                 # Packet forwarding
options         DIRECTED_BROADCAST      # Broadcast across subnets

because having *anything* else enabled stopped the compile <using
config.new <filename>, make depend, make> and/or link before final
binary time.  I went from 1.0-very-generic-indeed to be *sure* to
have everything we need.  Portmapping, for example <Sheesh>.  The
rest was hash-commented out, along with a few of the hardware options
I wouldn't need.  <Certain SCSI cards and the Warp> Does this still
happen under a -current build?


Kernel rebuilding part 2: "Hey Beavis, this fsck's..."

Because I'd hacked out a bunch of hardware options and probably done
a couple of extra filesystem selections <although not changed any of
the SCSI IDs> I was worried when I got

/dev/rsd1a: CANNOT READ: BLK 16
/dev/rsd1a: UNEXPECTED INCONSISTANCY, RUN fsck MANUALLY

on booting with the new kernel.  Odd, given no SCSI IDs had changed
between the kernels.  Filesystem errors?  No, given the previous
kernel booted perfectly.  Michael L.  Hitch <osymh@montana.edu>
mentioned SCSI ID changes - we had this problem when first installing
NetBSD off CD-ROM, but I'd forgotten about it.  d0h.  For some reason
the numbering of disks had changed with the new kernel - all it
needed was a quick edit to rc, exports and fstab to get the disks
mounted again, which was something of a relief ;-> If you're
recompiling, watch that disk numbering and keep a boot-floppy handy.

After that, no problem.  Mail me if you want the kernel and
config-file, or I'll up it to uni-regensburg if it's still relevant.

Currently we're running:  NFS clients from AmiTCP 3.beta and 4.demo
machines, XFS <shareware NFS client for Windows/Workgroups 3.11 with
TCP/IP>, and Samba <the brilliant NetBUI-via-TCP/IP Unix server that
serves the Windows'95 machines>.  It all works pretty much
seamlessly, although Samba wouldn't work on NetBSD until I installed
the security package (secr10aa) and got Crypt going on the password
file.  Even better is that we've finally got some ISO mastering
software adapted from Linux to work with NetBSD, so the Windows '95
CD can be built at last.  <There's no Win'95 building tools available
as yet>

It's easy when you know how, innit?  ;-> Thanks to all for their
suggestions so far.  Some more static column and it'll be X next...


<THP / almathera UK, who can now actually get on with the job in hand>