Unless you have great confidence that everything will work happily together, I very much suggest running the netboot server pieces in the following test configuration until you get your VAX client booted at least once or twice. And if you care, it also gives you a good feel for all the steps involved in the netbooting process.
The steps for the test run make the assumption that you're using an environment on your bootserver which allows for you to have multiple interactive Unix shells open concurrently -- either with X-windows or something along the lines of Linux's virtual consoles. It's not required that you have such a setup available, but it does certainly make things a lot easier to keep track of when testing your configuration.
There are some differences between the BSD and Linux mechanisms for RARP. Linux has the support for RARP built directly into the kernel, the BSDs use a more conventional setup with RARP services provided by a daemon.
There are some quirks to be aware of when using the RARP facilities of Linux. The biggest one being that the Linux kernel RARP code as of Linux 2.0.30 has a bug which makes life difficult later on when the bootloader is trying to communicate to the bootparamd server.
(STEP 1) Run the command `/sbin/ifconfig eth0 allmulti' to explicitly set the ethernet network interface to operate in promiscuous mode.
(STEP 2) Here's the RARP bug workaround. Prior to configuring the RARP table you must configure the kernel's ARP cache to contain information about the hardware ethernet address of your VAX client.
To add the entry to the ARP cache.
# /sbin/arp -s vaxclient 08:00:2b:16:59:bb
To examining the contents of the ARP cache.
# /sbin/arp -a
Address HWtype HWaddress Flags Mask Iface
vaxclient.test.net ether 08:00:2B:24:A8:D4 CM * eth0
(STEP 3) Populate the system RARP table with the VAX client's
information. You can manually enter the information one
entry at a time using the Linux /sbin/rarp command. I've
even written a simple shell script which will load the Linux
RARP table from the contents of /etc/ethers. This
script could be invoked at boot time as sort of a "poor man's"
rarpd. For now, we'll just do it by hand. Get your
VAX's hardware ethernet address handy.
To add the entry to the RARP table.
# /sbin/rarp -s vaxclient 08:00:2b:16:59:bb
To examine the contents of the RARP table
# /sbin/rarp -a
IP address HW type HW address
10.3.250.5 10Mbps Ethernet 08:00:2b:16:59:bb
Continue on to Running The NFS Server.
The RARP services under the BSDs are very well behaved and require very little from you apart from starting up the rarpd daemon. You can manually start it with the following command.
# /usr/sbin/rarpd -a
Or if you want to keep an eye on the activity of the rarpd daemon, you can run it with the `-d' option for debugging. This also runs the server in the foreground.
# /usr/sbin/rarpd -a -d
Continue on to Running The NFS Server.
The correct options for running rarpd under FreeBSD are `-a' and `-s':
# /usr/sbin/rarpd -a -s
If you want to run rarpd in the foreground to facilitate debugging, add the `-f' option:
# /usr/sbin/rarpd -a -s -f
Continue on to Running The NFS Server.
Depending on your system, you may need to run the NFS server components. Under the RedHat distribution of Linux, the NFS server has been configured to automatically run at start-up. NetBSD, OpenBSD, and older Linux distributions require some modifications to start-up files to have the servers start at boot time. Manually starting up the NFS server is easy. However, if your bootserver system is already running the NFS server components, then you shouldn't manually start the servers.
For more details on your bootserver's NFS server components, please see the man pages for mountd(8) and nfsd(8).
Manually starting the NFS server for NetBSD and OpenBSD
# /sbin/mountd
# /sbin/nfsd -tun 4
Manually starting the NFS server for Linux
# /sbin/rpc.mountd
# /sbin/rpc.nfsd
To manually start the nfs servers for FreeBSD, use these commands:
# /sbin/mountd -r
# /sbin/nfsd -tun 4
Note that the `-r' option on mountd is required to allow the target machine to access the swapfile that you have created for it.
Pull up another interactive Unix shell and be sure to `su' to root once you log in. Start the MOP server with the following options:
Under NetBSD and OpenBSD
# /usr/sbin/mopd -a -d
Under Linux and FreeBSD
# /usr/local/sbin/mopd -a -d
The `-a' tells the MOP server to listen for MOP requests on all network interfaces. You can actually specify the interface you want mopd to listen on but Karl Maftoum, the individual who ported mopd to Linux, gave the following bit of advice:
Be a little wary of specifying an interface, it is sanity checked (read hack), for it to work, so if you have an exotic network card try using `-a' if it is playing up.
The `-d' option causes mopd to run in debug mode. When mopd is actually transferring data to the VAX client, you will definitely know it. It spews lots of information in the shell window it's running in, and it also logs information to syslog. The mopd daemon will however sit very quietly until provoked with a MOP request.
Pull up another interactive Unix shell, su-ing to root. Run the bootparamd server with the following options:
Under NetBSD, OpenBSD, and FreeBSD
# /usr/sbin/rpc.bootparamd -d
Under Linux
# /usr/local/sbin/rpc.bootparamd -d
Again, the `-d' is for debug mode.
Finally, get to your VAX's console. The VAX systems still rely on the serial console for the NetBSD system console as NetBSD doesn't yet support the graphics consoles. If you are using the graphics console, you'll loose output once NetBSD starts booting. So from a serial console, issue the following command at the console prompt:
>>> b/100 esa0
You should immediately be prompted for a bootfile name. Enter in `mopboot' and press return.
Bootfile: mopboot
The VAX client will return with:
-ESA0
At first you should see some activity from the MOP server. Then after a short pause you'll see a great deal of activity from the MOP server. Many lines of MOP debug information should scroll in the MOP server window. Once that has stopped, you should notice some activity on the VAX client's console.
>> NetBSD/vax boot [980110 22:29] <<
: /netbsd
boot: client IP address: 10.3.250.20
It's the NetBSD bootloader, and it should be attempting to contact the bootparamd server. Switch your attention to the window with bootparamd running in it. Once the booting VAX has determined via RARP what it's IP address is, it sends out a `whoami' request to be answered by the bootparamd server. You should see the following response from the bootparamd server.
whoami got question for 10.3.250.5
This is host vaxclient.test.net
Returning vaxclient (none) 127.0.0.1
The VAX should take this information and use it to configure its name (vaxclient), it's domain name (in this case `none'), and the default route (it gets this value from the bootserver's default route which in this case is the dummy value 127.0.0.1).
When all goes well, you should get output like the following from your bootparamd server:
whoami got question for 10.3.250.5
This is host vaxclient.test.net
Returning vaxclient (none) 127.0.0.1
getfile got question for "vaxclient" and file "root"
returning server:bootserver path:/export/vaxclient/root address: 10.3.250.2
getfile got question for "vaxclient" and file "swap"
returning server:bootserver path:/export/vaxclient/swap \
address: 10.3.250.2
And output like this on the VAX serial console:
-ESA0
>> NetBSD/vax boot [980110 22:29] <<
: /netbsd
boot: client IP address: 10.3.250.5
boot: client name: vaxclient
root addr=10.3.250.2 path=/export/vaxclient/root
700416+38912+75784 start 0x9c078
Copyright (c) 1996, 1997 The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 1.3 (GENERIC) #1: Fri Jan 16 16:09:22 CET 1998
ragge@multivac:/usr/hej/src/sys/arch/vax/compile/GENERIC
realmem = 16646144
avail mem = 12690432
Using 812 buffers containing 831488 bytes of memory.
backplane0 (root)
cpu0 at backplane0: MicroVAX 3100 (KA41)
vsbus0 at backplane0
le0 at vsbus0: address 08:00:2b:16:59:bb
le0: 32 receive buffers, 8 transmit buffers
probing for SCSI controller at 0x200c0080...
result: 0x0 (0)
SCSI controller found.
probing for SCSI controller at 0x200c0080...
result: 0x0 (0)
SCSI controller found.
ncr0 at vsbus0: scsi-id 7
scsibus0 at ncr0: 8 targets
probing for SCSI controller at 0x200c0180...
result: 0x0 (0)
SCSI controller found.
ncr1 at vsbus0: scsi-id 7
scsibus1 at ncr1: 8 targets
boot device: le0
nfs_boot: trying RARP (and RPC/bootparam)
nfs_boot: client_addr=0xa03fa14
nfs_boot: server_addr=0xa03fa0a
nfs_boot: hostname=vaxclient
root on bootserver:/export/vaxclient/root
root file system type: nfs
fstab: /etc/fstab: No such file or directory
fstab: /etc/fstab: No such file or directory
fstab: /etc/fstab: No such file or directory
mount: /: unknown special file or file system.
/etc/rc.conf is not configured. Multiuser boot aborted.
Enter pathname of shell or RETURN for sh:
At this point, you have successfully booted the NetBSD/vax kernel from your bootserver. You will still need to make some modifications to the VAX client files in order to have NetBSD boot into a fully multiuser state.