The following section covers the details of setting up your own bootserver machine using the operating system of your choice. The configuration steps for all of the operating systems are nearly identical. But in the cases where there are exceptions, those exceptions are noted.
You will need to obtain copies of the NetBSD/vax bootloader in MOP format, the NetBSD/vax kernel, and the NetBSD/vax system binaries. Beyond this you will also need to configure a number of your bootserver's system files.
These files are arguably the most critical for booting up your VAX client system. You really need them.
The files required for netbooting live at the following location(s):
MOP format bootloader image
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-1.3/vax/installation/netboot/boot.mopformat
NetBSD/vax Kernel
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-1.3/vax/binary/kernel/gennetbsd.gz
These are files which make NetBSD useful to the mere mortal user who is looking to run NetBSD as useful Unix system. The basic guts of a Unix system are provided along with the all-important GNU development tools.
The files you need are located at:
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-1.3/vax/binary/sets/
Grab all the files in this directory. (Just so you know, it's about 36Megs worth of gzipped tar files). Setting aside the files you've collected above, we now move on to some basic modifications of the bootserver system files.
/etc/hosts
You'll need to add an entry to your bootserver's /etc/hosts
file reflecting the IP address and hostname you're intending to use
for your VAX. So I guess now would be a good time to figure out which
IP address you're going to give the machine and what you're going to
name it. Throughout this document I refer to the netboot VAX client
as `vaxclient' and the bootserver as `bootserver'.
# /etc/hosts example file
#
127.0.0.1 localhost
# other machines on my network
10.3.250.2 bootserver.test.net bootserver
10.3.250.3 junk.test.net junk
# added the VAX client (and friend)
10.3.250.5 vaxclient.test.net vaxclient
10.3.250.6 somevax.test.net somevax
# End of file
/etc/ethers
Create an /etc/ethers file with an entry for the VAX. The
format of /etc/ethers file entry is a single line with a
hardware ethernet address in colon separated form followed by the
machine name associated with that ethernet address.
# Example /etc/ethers file
08:00:2b:16:59:bb vaxclient
8:0:2b:16:54:a somevax
# End of file
See Appendix A at the end of this guide for information on obtaining your hardware ethernet address.
The MOP server that we'll be making use of is the same for all the
systems represented in this guide. By default the MOP server looks
for the MOP bootable images in the directory /tftpboot/mop/.
Make this directory and copy the file boot.mopformat which
you obtained earlier into the /tftpboot/mop directory.
Lastly, make a link from boot.mopformat to
MOPBOOT.SYS. The link to MOPBOOT.SYS is needed for
the examples in the remainder of this document.
# mkdir -p /tftpboot/mop
# mv boot.mopformat /tftpboot/mop
# cd /tftpboot/mop
# ln -s boot.mopformat MOPBOOT.SYS
The MOP server daemon is very particular about the names being in all uppercase and having the .SYS extension.
Now you'll need to set aside a place for holding the NetBSD snapshot
binaries on your bootserver machine. This directory will be used by
your VAX client as it's root filesystem. I made the directory
/export/vaxclient/root and used it to hold all the binaries.
Make the /export/vaxclient/root directory, or whatever
directory you want to use, and unarchive all the NetBSD snapshot
binaries into that directory. You'll need about 80Megs of free space
to hold the unarchived binaries so plan ahead.
# mkdir -p /export/vaxclient/root
# cd /export/vaxclient/root
# gzip -dc base.tgz | tar xvpf -
# gzip -dc comp.tgz | tar xvpf -
# gzip -dc etc.tgz | tar xvpf -
etc...
SPECIAL LINUX NOTE: The standard owner and group names for Linux don't match up with those of NetBSD. What this means is that when you untar the snapshot binaries on your Linux system, the untarring process will create the files with uids mapping to the Linux equivalent. The same holds for group id mappings.
Example: Under NetBSD the user `bin' has uid 3. Under RedHat Linux the user `bin' has uid 1. When you untar the snapshot files on your Linux system, the tar command will extract files in the archive belonging to `bin' with Linux's `bin' uid of 1. Later when you boot NetBSD from the Linux NFS filesystem, the files which should be owned by `bin' show up as being owned by the NetBSD `daemon' user. This is because `daemon' has uid 1 under NetBSD. Your NetBSD/vax system will still run, but you will experience difficulties using setuid and setgid programs under normal user accounts. I first noticed the problems with the NetBSD `ps' and `w' commands which are supposed to be setgid for the group `kmem'. But because the uids used were Linux uids, the programs were setuid to the group `wsrc'. Grrrr. I've not found a way to cleanly get around this problem yet.
Next you'll need to place the NetBSD kernel image in this directory.
Uncompress the the gennetbsd.gz file you obtained earlier and
copy it into the file named /export/vaxclient/root/netbsd.
# gzip -dc gennetbsd.gz > /export/vaxclient/root/netbsd
You'll also need to create a system swapfile for use by NetBSD. I
placed it right in the /export/vaxclient directory as it
seemed like a good place to keep it.
To create a 16Meg swapfile, I used:
# dd if=/dev/zero of=/export/vaxclient/swap bs=4096 count=4096
Finally, you will need to create a /dev/console device file in the
VAX client's /dev directory. The NetBSD/vax kernel will need
this when the system boots. You'll need to make the device file on
the bootserver.
# cd /export/vaxclient/root/dev
# mknod console c 0 0
Depending on your operating system, the format of the /etc/exports
file can vary. Presently there are two formats to deal with.
Edit your /etc/exports file to contain the information about
your VAX client's NFS root directory.
# Example /etc/exports for NetBSD and OpenBSD
/home
/share
/export/vaxclient/root -maproot=root vaxclient.test.net
/export/vaxclient/swap -maproot=root vaxclient.test.net
# end of /etc/exports
The options following the mount name specify full root access privileges for the VAX client. Full root access is required for the netbooted VAX to function properly. You should be aware that there are some security risks in allowing root write access to NFS mounted filesystems. However, this guide assumes you're working within a trusted environment.
As opposed to adding the line for the swap file separately, you could
have added the `-alldirs' flag to the list of options under the export
entry for /export/vaxclient/root. But that may give you a
bit more than you bargain for. See the manpage for exports(5) if
you're curious. Having come over from Linux, Solaris, and IRIX --
I found the BSD NFS server behavior a bit different from what I was
used to.
You may continue on to Setting Up /etc/bootparams.
Edit your /etc/exports file to contain the information about
the directory you intend to NFS export as the root filesystem for your
VAX.
# Example /etc/exports for Linux
/home
/share
/export/vaxclient/root vaxclient.test.net(rw,no_root_squash)
/export/vaxclient/swap vaxclient.text.net(rw,no_root_squash)
# end of /etc/exports
The options in `()' specify that full root access privileges are allowed for the machine vaxclient. This is necessary for the netbooted VAX to function properly. This does present some security risks, but I'll operate under the assumption that you're in a fairly trusted environment.
After making changes to /etc/exports you'll have to `kill
-HUP' your mountd and nfsd daemons so they re-read the
/etc/exports file. Or you can go with the brute-force system
reboot if you prefer. (One prerequisite is that you're going to have
to be running all the appropriate NFS server daemons for NFS exporting
to work.)
You may continue on to Setting up /etc/bootparams.
FreeBSD only allows the export of entire filesystems, not
directories. In your /etc/exports file you must make sure
that the location in which you've stored the NetBSD/vax binaries is
specified in terms of its root filesystem, and NOT in terms of the
location of the NetBSD/vax directory.
If you've created a root directory for your NetBSD/Vax machine in
/usr/export/vaxclient/root, for example, then your
/etc/exports file must state the filesystem on which this
directory resides, and NOT the name of the directory itself.
To get an idea of how to create your exports file, take a look at your current mount points:
# mount
/dev/wd0a on / (local)
/dev/wd0s1f on /usr (local)
/dev/wd1c on /usr/home (local)
/dev/wd0s1e on /var (local)
procfs on /proc (local)
In this case, since /usr/export/vaxclient/root is part of the
/usr filesystem, the /etc/exports file must indicate
/usr, and NOT /usr/export/vaxclient/root:
# cat /etc/exports
/usr -alldirs -maproot=root vaxclient.test.net
Unlike other versions of UNIX, the following will NOT work:
# cat /etc/exports
/usr/export/vaxclient/root -alldirs -maproot=root vaxclient.test.net
This is because /usr/export/vaxclient/root is not a
filesystem in its own right, but a directory within another
filesystem.
Note that the `-alldirs' flag is required, this is because unlike
NetBSD and some other UNIX variants, FreeBSD will not allow
/etc/exports to contain references to files, only
filesystems. Access to the NetBSD/vax swap file is handled during the
startup of mountd below.
You may continue on to Setting up /etc/bootparams.
/etc/bootparamsThe /etc/bootparams file contains the information the
bootparamd server will pass along to the booting VAX client. It
contains information about the netbooting machine's identity, where
it's NFS root filesystem is located, and where it's swapfile is
located. You can also specify a dumpfile.
Each entry in the /etc/bootparams file consists of a single
line of text.
# Example /etc/bootparams
vaxclient root=bootserver:/export/vaxclient/root \
swap=bootserver:/export/vaxclient/swap
# End of file
The man page for bootparams claims that you may continue the entry across lines using the "\" continuation delimiter, but I haven't had any success with using it under Linux at least. I now habitually keep each entry on a single line. (Just pretend that you don't see the "\" used above in the example and that the line continues off the right side of the page).