[1202] in NetBSD-Development
Re: Some notes from a 1.1 install
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Jan 21 14:27:15 1996
To: nathanw@MIT.EDU
Cc: netbsd-dev@MIT.EDU
In-Reply-To: Your message of "Sun, 21 Jan 1996 11:32:58 EST."
<9601211632.AA06512@sciences.MIT.EDU>
Date: Sun, 21 Jan 1996 14:25:37 EST
From: Greg Hudson <ghudson@MIT.EDU>
Thanks for the testing effort; it's quite useful.
> Of that, 90 minutes was in the part currently labeled as "this will
> take about 10 minutes", from installing the base pack to copying
> over the kernel. I expect 90 minutes to be the minimum time for this
> section, given that I tested it at an hour when network load was
> otherwise very light.
I've expanded the time estimate in unpack.sh to note that it will take
at least 90 minutes from a frame relay site; this will at least give
people the opportunity to go get something to eat instead of hanging
around and waiting. :)
(Ideally, the user should be able to answer all the questions the
install program asks before unpacking, remove the floppy, and have the
machine reboot afterwards, but that's not going to be a feature of the
1.1 install.)
> Notably, NFS performance over the frame relay network peaks at about
> 4Kb/s, while FTP is often 50% faster. It may be too late in the
> development cycle to make the install procedure use FTP, but it
> could easily shave half an hour off of installations in ILG's.
Doing an install via FTP without requiring extra temporary space is
possible, but tricky (I think it requires writing code).
> The end of the install script could mention removing the
> floppy once more before rebooting.
I've added a line for this.
> I'm not sure when the boot manager can be installed; will it
> work if space has been cleared for NetBSD but no partition exists
> for it? I dealt by booting to DOS and installing the boot manager
> after NetBSD had been installed.
The documentation suggests you do it while you have two DOS
partitions, since both BOOTEASY and OS Boot Select only care where
partitions are. You do need to have both partitions present, though,
so once you delete the DOS partition you need to create a NetBSD
partition (either using the NetBSD install disk or by hand with
pfdisk) before running the boot manager.
> The default umask for root is 0; this strikes me as too generous. In
> a similar vein of paranoia, we may wish to mention the desirablilty
> of getting a srvtab for protected access to the machine.
I decided to leave examination of this issue until later.
> There is some minor disagreement with the documentation
> (revision 1.20 of /afs/sipb/project/doc/netbsd) ; the last part of
> step 5 is to turn on the line in /etc/ttys that runs /etc/athena/dm.
> Lots of terminal lines follow that line on the installed system.
(Note that revision 1.20 of the documentation is the *last* revision,
since I haven't checked in the updates.) I've brought this part of
the documentation up to date, thanks.
> if grep -q kernfs /mnt/etc/fstab; then
> mkdir -p -m 755 /mnt/kern /mnt/proc
> cat /usr/distrib/fstab.add >>/mnt/etc/fstab
> fi
> Shouldn't that grep be grep -v, so that it installs the entries in
> fstab if they aren't already installed?
grep -v would check for the existence of lines that weren't kernfs,
not very useful. I've added an "else" before the commands, as in the
other checks. (The Bourne shell doesn't provide a method of negating
if statements.)
> There are still a couple of problems that I need to solve. The
> machine has three serial ports, and NetBSD only finds two, and the
> one that isn't the mouse doesn't seem to work (attached to a VT220).
The default kernel only looks for two serial ports, presumably because
the probe for a third serial port conflicts with some devices that use
IRQ 5. You'll need to build a custom kernel to use the third serial
port. I'm not familiar with a failure mode where a serial port
doesn't work; I assume you're using something like kermit (add modem;
kermit) to test it, and you have the data rates and everything
agreeing with the VT220?
> The bigger problem is that NetBSD's NFS client doesn't seem to work
> with a Linux NFS server; I get 'stale file handle' errors
> immediately upon mounting the filesystem.
Given the history and quality of the implementations in question, I
would tend to blame the Linux NFS server here, but I could be wrong.
Certainly, it would be easier to debug from that side.
(I don't know if you guys have been having problems with the Linux NFS
server using Linux clients; one of the most concrete advantages of
NetBSD over Linux is that it has a fast and reliable in-kernel NFS
server implementation.)