The VAX Network Booting HOWTO
Brian Chase, bdc@world.std.com
v0.5, 31 Jan 1998
This is a guide to network booting DEC VAXstation and MicroVAX systems
with NetBSD/vax from a Unix based bootserver. The information in this
guide does not apply in a general way to bootserving. It is specifi-
cally geared towards MOP initiated bootserving as is common to DEC's
line of VAX computers. The latest version of this document can be
obtained from: <http://world.std.com/~bdc/projects/vaxen/> Comments,
questions, and corrections are welcome and expected.
______________________________________________________________________
Table of Contents:
1. Introduction
1.1. Overview of The Netbooting Process
1.2. Supported Platforms
1.3. Supported Platform Quirks
1.3.1. Display Limitations
1.3.2. Memory Limitations
1.3.3. Ethernet Device Limitations
1.3.4. Disk Limitations
1.4. Acknowledgments
2. Getting Your System up to Speed
2.1. Modifications for Linux
2.1.1. Preparing Your Linux Kernel
2.1.2. Obtaining Additional Software Needed by Linux
2.2. Modifications for FreeBSD (Contributed by Kevin McQuiggin)
2.3. Modifications for Solaris
2.4. Modifications for IRIX
2.5. Modifications for NeXTSTEP
3. Bootserver Configuration
3.1. Obtaining The NetBSD/vax Kernel and MOP Bootloader Images
3.2. Obtaining The NetBSD/vax Binaries
3.3. Editing Some Relevant Files
3.4. Setting up The MOP Bootloader Image Directory
3.5. Setting up The VAX Client's NFS Root Directory and Swap File
3.6. Setting up The NFS Root Directory for Export
3.6.1. NetBSD and OpenBSD Exports File
3.6.2. Linux Exports File
3.6.3. FreeBSD Exports File (Contributed by Kevin McQuiggin)
3.7. Setting up
4. Performing A Test Run
4.1. Setting up The RARP Table
4.1.1. Ethernet and RARP Setup under Linux
4.1.2. RARP Setup under NetBSD and OpenBSD
4.1.3. RARP Setup under FreeBSD (Contributed by Kevin McQuiggin)
4.2. Running The NFS Server
4.2.1. The NetBSD and OpenBSD NFS Servers
4.2.2. The Linux NFS Server
4.2.3. The FreeBSD NFS Server (Contributed by Kevin McQuiggin)
4.3. Running The MOP Server
4.4. Running The bootparamd Server
4.5. Booting from The VAX Client Console
5. Multiuser Configuration
5.1. Entering Single User Mode
5.2. Modifying The Configuration
5.3. Booting up Multiuser
6. Automating The Bootserver and Booting Process
6.1. Automating The Bootserver under NetBSD
6.2. Automating The Bootserver under OpenBSD
6.3. Automating The Bootserver under Linux
6.4. Automating The Bootserver under FreeBSD
6.5. More on MOP (or Look Mom, No Hands!)
7. Something Went Wrong
7.1. Bootloader Fails to Load The Kernel
7.2. Boot Hangs - output buffer busy
7.3. Boot Hangs - kernel stops, but I can ping client
8. APPENDIX A - Obtaining Your Hardware Ethernet Address
9. APPENDIX B - Scripts for Linux
______________________________________________________________________
1. Introduction
After acquiring a VAXstation 3100, I was interested in making the
machine a bit more useful by running some type of Unix operating
system on it. Thoughts of running VAX/VMS crossed my mind for a few
seconds, but I quickly regained my sanity. VMS just isn't Unix.
(Depending on your viewpoint that can be read as either an insult or a
compliment to either of the two operating systems). Then there was
Ultrix, and although it would satisfy my desire to run Unix -- Ultrix
just isn't the best version of Unix I've ever worked with. In fact it
is probably the worst version of Unix I've ever worked with. The one
remaining option was to run NetBSD/vax. An end goal at hand, my quest
began.
Although still in it's early stages, NetBSD/vax is pleasingly
functional in its support of the ``VAXstation and MicroVAX systems''
discussed in this guide. NetBSD/vax has addressed my desire to run a
modern Unix on my personal slice of DEC VAX history. Still, it was no
small task to get from the point of having a VAXstation without an
operating system to the point where the machine booted up to a
cheerful login prompt. In order to make the lives of others easier as
they too attempt to breathe new life into their sleepy VAX systems, I
have assembled this guide.
Update: With the release of NetBSD 1.3, support for the netbooting of
NetBSD/vax has been officially incorporated into a full fledged
release of NetBSD/vax.
1.1. Overview of The Netbooting Process
Before we even get started, it will help you to have a general
understanding of exactly what takes place during the netbooting
process.
There are three phases to the netbooting process: (1) MOP loading the
NetBSD/vax bootloader from the MOP server and starting it, (2) the
bootloader starting the NetBSD/vax kernel, (3) the kernel NFS mounting
the root filesystem and proceeding with normal startup.
MOP is short for Maintenance Operations Protocol. It's a DEC
proprietary communications protocol used in many DEC systems for
things like, well, netbooting workstations. The VAXstations, in
addition to many other VAXen have the client side support for MOP
built into their system ROMs. Without this built-in MOP client code,
we wouldn't get very far in netbooting the machines. This is because
MOP provides the means by which the NetBSD/vax bootloader is
transferred to the VAX client. To boot a machine from the network
using MOP you need to have a MOP server in addition to your VAX's
client implementation of MOP. Setting up a MOP server on a bootserver
machine is covered later in the HOWTO.
After using MOP to transfer the NetBSD/vax second stage bootloader
from the bootserver, the bootloader begins executing. The bootloader
then sends a RARP request out on the local network to determine the IP
address which should be assigned to the VAX client. The IP address to
assign to the VAX is based on its hardware ethernet address. You'll
have to specify the mappings of ethernet address to IP addresses, but
this is covered in the HOWTO. We will configure the bootserver as the
machine for answering the RARP requests.
Following the determination of the VAX's IP address, the bootloader
begins a dialog with the bootparamd server. The bootparamd server
generally runs along with the MOP server on the bootserver machine.
The dialog with bootparamd lets the VAX client know important things
like, where to find the NFS filesystem on which the NetBSD/vax kernel
lives.
After gathering information from bootparamd, the bootloader can NFS
mount the appropriate root filesystem and transfer execution to the
NetBSD/vax kernel located on that filesystem. From this point on, the
booting of NetBSD/vax goes much the same way as it would from a local
disk.
For a more detailed overview of netbooting, see the NetBSD man page
for diskless(8).
Based on the phases of netbooting described above, you can see that
we've got a number of requirements for successfully booting a VAX
client from the network. Those requirements being: the presence of a
MOP server, a machine with support for answering RARP requests, a
bootparamd server, and an NFS server to host the VAX's root
filesystem.
1.2. Supported Platforms
There are several members of the VAXstation family which I know work
with the netboot setup as described in this document. These machines
are all older models of VAXstation.
VAXstation 2000, VAXstation 3100/M30, VAXstation 3100/M38, VAXstation
3100/M40, VAXstation 3100/M48, and VAXstation 3100/M76
In addition to the VAXstations, several of the MicroVAX and VAXserver
named systems may also be successfully netbooted.
MicroVAX 2000, MicroVAX 3100/M10, MicroVAX 3100/M10e, MicroVAX
3100/M20, MicroVAX 3100/M20e, and VAXserver 3100
1.3. Supported Platform Quirks
Although a fairly broad range of systems is supported, this support
tends to come with certain limitations.
1.3.1. Display Limitations
The NetBSD/vax port presently has no support included for display
hardware. None of the display framebuffers or enhanced display
adapters are supported. They are not even supported in the capacity
of a console device. The only non pseudo terminal support for direct
interaction with a booted NetBSD/vax system is through the serial
console. You will either need a serial terminal such as a VT220, or
you will need to interface the VAX to another system such a PC running
a communications software package.
1.3.2. Memory Limitations
Presently, the VAXstation 3100's and MicroVAX 3100's are unable to
boot from the network when they have memory configurations greater
than 16Megs. The memory areas critical to the operation of the Lance
ethernet device get mapped in such a way that memory configurations of
more than 16Megs confuse NetBSD's interaction with the Lance device.
The workaround for this stumbling block is the common sense solution
of removing memory until the system has no greater than 16Megs of RAM.
Yes, it's painful thing to do if you've got 32Megs of RAM in your
workstation. But then you have to ask yourself, do I want an
oversized paperweight with 32Megs of RAM or do I want a nifty
operational NetBSD/vax system with 16Megs?
See ``Boot Hangs - output buffer busy'' for more details on this
problem behavior.
1.3.3. Ethernet Device Limitations
You cannot netboot VAXstation and MicroVAX systems which do not have
the lance ethernet device present. The reason for the lance ethernet
requirement is that there is no support in the bootloader for Q-bus,
Unibus, or other non-lance ethernet devices. Examples of specific
devices which are NOT supported by the bootloader at this time include
DEQNA, DELQA, DEUNA, and DELUA. Basically, if it's not a lance
ethernet device you won't be netbooting based on the information
contained in this document.
1.3.4. Disk Limitations
The local disk support for the various platforms is somewhat flaky at
the moment. This is one of the reasons that netbooting these systems
is presently the most viable way to operate these systems.
Of the supported systems, the VAXstation 2000 and the VAXstation
3100/M76 have the best disk support. This is mainly due to those
being the types of systems on which the majority of the VAXstation
kernel development was carried out. By "best disk support" I mean
that the kernel device drivers support the more efficient DMA I/O data
transfers on the disk controllers of these machines. In the case of
the VAXstation 2000, both its MFM (ST506) and SCSI controllers are
supported by NetBSD/vax. In the case of the VAXstation 3100/M76 it
has a pair of SCSI controllers integrated into the main system board.
Both of the these SCSI controllers are supported.
The other systems, the VAXstation 3100 M30/M38/M40/M48, do have
support for SCSI controllers present in them. The model 30-48
VAXstation 3100's have separate daughter boards on which their disk
I/O controllers reside. Two types of controller boards were made for
these machines. One was board contained both an MFM (ST506) controller
and a SCSI controller. The other board had two SCSI controllers built
into it. Only the SCSI controllers on these daughter boards are
supported by the NetBSD/vax kernel, and presently the drivers must be
modified in such a way that they run in a degraded mode of Programmed
I/O (PIO) data transfers.
In my experience the PIO mode works reliably, but the read and write
rates to the disks are a painfully slow 30KB/sec. Using the NFS
mounted filesystems are significantly faster unless your network is
really heavily loaded.
I'm not familiar with the MicroVAX systems so I don't know to what
extent disk I/O is supported with them. The MicroVAX 2000 mainboard,
being identical in design to the VAXstation 2000, will have fully
functional NetBSD/vax controller drivers. As for the listed MicroVAX
3100 models, they deviate a bit more in design from their VAXstation
3100 siblings. I would suppose that if a particular MicroVAX 3100 can
be netbooted, and if the MicroVAX 3100's use the same disk controllers
as the VAXstation 3100's, then there's a good chance that the SCSI
drivers will at least work in the degraded PIO transfer mode. Keep in
mind that the MicroVAX 3100 information is speculative at this point.
1.4. Acknowledgments
Many thanks go out to those of both the NetBSD/vax community as well
as members of the VAX/Linux porting efforts. I would like to thank in
particular:
In alphabetical order
Bertram Barth
For all the excellent work on the NetBSD with VAXstation 3100
support. Bertram is truly a port-vax mailing list hero.
Additional thanks go out to Bertram for adding SCSI controller
autodetection code to allow systems with less than two SCSI
controllers to boot properly.
Enrik Berkhan
For researching and finding a workaround for the difficulties
with the bootparamd server under the current Linux
implementation of RARP.
Bruce Calder
For visiting on a weekend and doing most of the work to get the
NetBSD kernel image to actually load during our first attempts
at netbooting.
Antonio Carlini
For clarification on the various types, designs, and
designations of VAX systems.
Mats O. Jansson
For mopd, without mopd none of this would be possible.
Karl Maftoum
For porting mopd to Linux, else this guide would be quite thin,
for providing lots of pointers when I first got my VAXstation
3100, and also for charging headlong into the perils of porting
Linux to the VAX architecture.
Anders Magnusson (Ragge)
For all the excellent work on the NetBSD/vax port and being very
helpful in general. Yet another port-vax hero. Without Ragge,
there wouldn't be a NetBSD/vax port. Many thanks for the
excellent work on 1.3 as well.
Kevin McQuiggin
For creating the FreeBSD sections. That's one less Unix left
unexplained.
Mattias Nordlund
For pointing me to the Linux version of bootparamd.
Tim Shoppa
For providing me with all sorts of excellent information to all
my VAX hardware questions. Not to mention his hand delivering a
pair of VAXstation 3100's to me on a trip from Vancouver in
Canada to Southern California. Tim also provided an interesting
account of how he once traveled on a plane with a PDP-11 as
carry-on luggage.
Many thanks in general to the NetBSD/vax, NetBSD, and Linux
communities for providing a lot of positive feedback on this HOWTO.
2. Getting Your System up to Speed
This section provides information on adding any missing pieces your
operating system may require in order to get it to properly function
as a bootserver environment for your VAX. Of the several operating
systems VAX bootserving has been set up on, only Linux and FreeBSD
require any noteworthy additions. Both NetBSD and OpenBSD have all
the components necessary for netbooting preloaded. If you're planning
on using NetBSD or OpenBSD for your bootserver, you may move on to the
``Bootserver Configuration'' section of the HOWTO at this time.
2.1. Modifications for Linux
Unfortunately your ordinary distribution of Linux is somewhat short on
utilities for adequately netbooting NetBSD on DEC VAX hardware. But
thanks to the BSD people, all the necessary networking software
resources are ready to hijack. In fact, all the needed software
pieces have already been modified to run under Linux -- you just have
to go out and gather them up.
2.1.1. Preparing Your Linux Kernel
There are a couple of things which need to be included your Linux
kernel in order for netbooting to work properly.
RARP
First you need to make sure you've got RARP support compiled in. If
the file /proc/net/rarp doesn't exist then you need to do one of two
things: (1) It may be that RARP was compiled as a loadable module for
your kernel. If this is the case then you'll need to `insmod' the
/lib/modules/(linux version)/ipv4/rarp.o module. (2) If you don't
already have RARP compiled into your kernel, you will need to
reconfigure and recompile Linux with RARP support added. Since the
RARP code is small, I recommend just compiling it directly into the
kernel.
Multicast
In addition to RARP, it is also recommended that you compile in the IP
multicast code for Linux.
Compiling in IP multicast was how I initially got my network interface
to operate in promiscuous mode. There's an easier way to achieve the
same effect and that is with the command `ifconfig eth0 allmulti'
which according to the ifconfig man page does the following:
[-]allmulti
Enable or disable the promiscuous mode of the
interface. This means that all incoming frames get
sent to the network layer of the system kernel,
allowing for networking monitoring.
Running the network interface in promiscuous mode is necessary for the
MOP server software which will be discussed later in this guide.
There is some still some speculation (on my part at least) about the
necessity of compiling in multicast support. I've found that I don't
need it with the Linux driver for my NE2000 clone card. Other network
card drivers may behave differently (more speculation on my part). I
guess more research and knowledge is required.
Unless you know otherwise, go ahead and compile your Linux kernel with
IP multicast support. There's no harm in doing it.
2.1.2. Obtaining Additional Software Needed by Linux
Before you begin, you'll need to grab all the necessary components to
turn your Linux system into a lean mean netbooting machine.
The MOP Server
The MOP server that Linux uses is the same MOP server used by the
BSDs, only it has some modifications to allow it to run under Linux.
The MOP server is used by the VAX client to load the NetBSD/vax
bootloader.
The MOP Server software for Linux is available from:
<ftp://ftp.stacken.kth.se/pub/OS/NetBSD/mopd/mopd-linux-2.5.3.tar.gz>
<ftp://ftp.canberra.edu.au/pub/ise/linux-vax/tools/mopd/mopd-
linux-2.5.3.tar.gz>
Building The MOP Server
The MOP server software is contained in the file mopd-
linux-2.3.5.tar.gz which you have hopefully grabbed already.
Extracting the files from this archive will create a README, a common
code directory, and directories for the various utilities of the mopd
package. At this point we're only concerned with the mopd directory
which contains the source code for the MOP server. The other
directories contain the code for various MOP server debugging
utilities.
Run `make' inside the ./mopd-linux/mopd directory. This will build
the mopd MOP server daemon.
Installing The MOP Server
I choose to place the MOP server in the /usr/local/sbin directory on
my Linux system. You may place them where ever it makes the most
sense to you, but the examples in the remainder of the HOWTO will
assume that the executables reside in /usr/local/sbin.
# mkdir -p /usr/local/sbin
# cp ./mopd-linux/mopd/mopd /usr/local/sbin
The bootparamd Server
If your Linux distribution didn't come with a bootparamd or an
rpc.bootparamd daemon then you'll need to get one. The RedHat 5.0
Linux distribution comes with a bootparamd server, but my RedHat 4.0
installed system didn't have one. If you're running on a system which
does have the daemon, then move on to the ``Bootserver Configuration''
section. It's likely that a number of other distributions are missing
this server daemon. No problem though, you just need to pick up an
old version of NetKit for Linux:
<ftp://ftp.uk.linux.org/pub/linux/Networking/base/attic/NetKit-0.09.tar.gz>
Building The bootparamd Server
The bootparamd server rpc.bootparamd is contained in the
NetKit-0.09.tar.gz file.
Extracting the files from this archive will give you the other
directories containing network servers and utils. We're only
interested in two of the directories: rpcgen and rpc.bootparamd. The
first, rpcgen, contains the source for a utility needed for the
compilation of the rpc.bootparamd server. The second directory,
rpc.bootparamd, appropriately contains the source for the bootparamd
server.
Run `make' inside of ./NetKit-0.09/rpcgen and then run `make' inside
of ./NetKit-0.09/rpc.bootparamd. This will build the bootparamd
server daemon.
Installing The bootparamd Server
Copy the bootparamd server into /usr/local/sbin, or which ever
location you are using to hold these non standard server daemons. The
remainder of the HOWTO will assume that you've copied them to
/usr/local/sbin.
# cp ./NetKit-0.09/rpc.bootparamd/bootparamd /usr/local/sbin
You may continue on to ``Bootserver Configuration''
2.2. Modifications for FreeBSD (Contributed by Kevin McQuiggin)
Before you begin, you'll need to get a copy of the mopd MOP server
daemon to allow your FreeBSD system to operate as a bootserver.
The MOP Server
The MOP server used is the standard MOP server used by the other BSD
derived systems like NetBSD and OpenBSD. Depending on the version of
FreeBSD you're running, modifications to the mopd source may be
necessary. The MOP server is used by the VAX client to load the
NetBSD/vax bootloader.
The MOP Server software is available from:
<ftp://ftp.stacken.kth.se/pub/OS/NetBSD/mopd/mopd-2.5.3.tar.gz>
Building The MOP Server
The MOP server software is contained in the file mopd-2.3.5.tar.gz
which you have hopefully grabbed already.
Version 2.5.3 of mopd is configured for use with FreeBSD versions 2.1
and lower. If you are running FreeBSD 2.2 or later then you have to
make some minor changes to one of mopd's source files. The next
release of mopd will fix this, but for now here are the changes you
must make.
The file that must be modified is put.c. It is in the mopd
distribution's ./mopd-2.5.3/common directory. Add the following 3
lines to the #includes section at the start of the file:
#ifdef __FreeBSD__
#include <osreldate.h>
#endif
Next, there are 2 places within the file where the symbol __FreeBSD__
is checked to see if it is defined:
#if !defined(__FreeBSD__)
Change each of these lines to:
#if !defined(__FreeBSD__) || __FreeBSD_version >= 220000
Make the appropriate changes to the put.c if you're running a version
of FreeBSD greater than 2.1. Then switch to the mopd daemon's
directory and build the mopd daemon.
# cd ./mopd-2.5.3/mopd
# make
This will rebuild a usable copy of mopd for use with FreeBSD versions
2.2 and later.
Installing The MOP Server
Now that you've built your mopd server daemon, I suggest copying it
into /usr/local/sbin. You may place the server where ever it makes
the most sense to you, but the examples in the remainder of the HOWTO
will assume that the mopd executable resides in /usr/local/sbin.
# mkdir -p /usr/local/sbin
# cp ./mopd-2.5.3/mopd/mopd /usr/local/sbin
You may continue on to ``Bootserver Configuration''
2.3. Modifications for Solaris not completed
2.4. Modifications for IRIX not completed
2.5. Modifications for NeXTSTEP not completed
3. Bootserver Configuration
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.
3.1. Obtaining The NetBSD/vax Kernel and MOP Bootloader Images
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>
3.2. Obtaining The NetBSD/vax Binaries
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.
3.3. Editing Some Relevant 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.
3.4. Setting up The MOP Bootloader Image Directory
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.
3.5. Setting up The VAX Client's NFS Root Directory and Swap File
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
3.6. Setting up The NFS Root Directory for Export
Depending on your operating system, the format of the /etc/exports
file can vary. Presently there are two formats to deal with.
3.6.1. NetBSD and OpenBSD Exports File
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''.
3.6.2. Linux Exports File
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''.
3.6.3. FreeBSD Exports File (Contributed by Kevin McQuiggin)
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''.
3.7. Setting up /etc/bootparams
The /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 " 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).
4. Performing A Test Run
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.
4.1. Setting up The RARP Table
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.
4.1.1. Ethernet and RARP Setup under Linux
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''.
4.1.2. RARP Setup under NetBSD and OpenBSD
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''.
4.1.3.
RARP Setup under FreeBSD (Contributed by Kevin McQuiggin)
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''.
4.2. 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).
4.2.1. The NetBSD and OpenBSD NFS Servers
Manually starting the NFS server for NetBSD and OpenBSD
# /sbin/mountd
# /sbin/nfsd -tun 4
4.2.2. The Linux NFS Server
Manually starting the NFS server for Linux
# /sbin/rpc.mountd
# /sbin/rpc.nfsd
4.2.3.
The FreeBSD NFS Server (Contributed by Kevin McQuiggin)
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.
4.3. Running The MOP Server
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.
4.4. Running The bootparamd Server
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.
4.5. Booting from The VAX Client Console
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.
5. Multiuser Configuration
In the last section we'd gotten you to the point where NetBSD had
successfully booted on your VAX system. However, the client's system
configuration files are still in need of some changes. These changes
allow the VAX to fully function as a multiuser system. A system which
is running an array of network services, and one that provides remote
logins through telnet.
5.1. Entering Single User Mode
The last bit of information we received from our booting VAX was the
following.
/etc/rc.conf is not configured. Multiuser boot aborted.
Enter pathname of shell or RETURN for sh:
Press the RETURN key. You'll be prompted for your terminal type,
enter it and press RETURN. You'll be dropped into single user mode on
the VAX. If you're not sure of what terminal type you've got `vt100'
is a fairly safe value for many serial terminals as well as
communication software programs.
/etc/rc.conf is not configured. Multiuser boot aborted.
Enter pathname of shell or RETURN for sh:
Terminal type? vt100
Don't login as root, use the su command.
#
From here you've got access to all your standard Unix utilities. You
may choose to edit the VAX client configuration files either here in
the privileged single user shell, or you may edit the configuration
files directly on the bootserver where the data resides. I'll
continue the examples with editing the files from within the booted
VAX client. Since you've put so much work into getting your machine
running, you may as well do something useful with right off.
5.2. Modifying The Configuration
Creating The Device Files
One of the things that needs to be done is creating the device files
needed by the NetBSD/vax device drivers. This is a simple operation
most commonly done with the MAKEDEV script.
# cd /dev
# ./MAKEDEV all
Name Resolution
If you want your VAX to talk to other systems on your network by name,
you'll need to set up your name resolution facilities. You're options
include using the hosts file, DNS, NIS, or any combination of these
facilities that suit your particular needs.
If you don't already have an NIS or DNS setup in place, then the
simplest of these options is to just add the host and IP addresses to
the /etc/hosts file.
Creating /etc/fstab
Next we move on to creating a simple /etc/fstab file for the booting
VAX. The file doesn't actually need to contain anything, it just
needs to exist. A simple `touch /etc/fstab' will suffice.
However if you want the VAX to automatically make use of the swap file
at boot time, you'll need to place the swap file information a entry
in /etc/fstab. You will also need to create a mount point for the
file. I suggest using a directory named /swap.
# mkdir /swap
Then edit the VAX client's /etc/fstab file to indicate where the swap
file is located and where it's being mounted to.
# Example /etc/fstab
bootserver:/export/vaxclient/swap none swap sw,nfsmntpt=/swap
You may also add entries for any NFS filesystems that you'd like the
VAX to mount during boot up.
Creating /etc/myname, /etc/defaultdomain, and /etc/mygate
These files are optional, but are used to indicate the local hostname,
the host's domainname, and the default route for the VAX client. In
this document's example, the file /etc/myname should contain
`vaxclient', the file /etc/defaultdomain should contain `test.net',
and /etc/mygate would contain `10.3.250.5' since we're just talking to
machines on the local network.
You may alternatively specify the hostname, domainname, and default
route in the /etc/rc.conf file. See the next section for some
additional information on this file.
Modifying /etc/rc.conf
The /etc/rc.conf file is a very important configuration file which
dictates the behavior of how your VAX boots into multiuser mode. You
should look through the file and set the available options such that
they reflect how you boot your system. Here's a couple of important
options which should be set.
rc_configured=YES
nfs_client=YES
5.3. Booting up Multiuser
Having made some changes to the base NetBSD/vax installation, you
should now be ready to run your system in multiuser mode. Prepare to
be dangerous. Rebooting the system, you should see something along
the lines of the following.
-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
Automatic boot in progress: starting file system checks.
mount: /: unknown special file or file system.
setting tty flags
starting network
hostname: vaxclient
domainname: test.net
configuring network interfaces:.
swapctl: adding bootserver:/export/vaxclient/swap as \
swap device at priority 0
starting system logger
checking for core dump...
savecore: no core dump (no dumpdev)
starting rpc daemons: portmap.
starting nfs daemons: nfsiod.
creating runtime link editor directory cache.
checking quotas: done.
building databases...
clearing /tmp
updating motd.
standard daemons: update cron.
starting network daemons: inetd.
starting local daemons:.
Fri Jan 23 17:10:09 PST 1998
Jan 23 17:10:11 vaxclient init: kernel security level changed from 0 to 1
NetBSD/vax (vaxclient) (console)
login:
6. Automating The Bootserver and Booting Process
No, you're not forever doomed to manually prepare your bootserver for
booting up your VAX client. You just have to make a few changes to
what your bootserver runs when it first boots up.
6.1. Automating The Bootserver under NetBSD
Hey, this is easy! That's what I thought when I figured out how to
start all the nifty bootserver related daemons at boot time under
NetBSD. On your NetBSD bootserver, you will need to edit the
/etc/rc.conf file, a file which is a virtual network services
supermarket.
# example lines from /etc/rc.conf and how they should be set:
bootparamd=YES
bootparamd_flags=""
rarpd=YES
rarpd_flags="-a"
mopd=YES
mopd_flags="-a"
nfs_server=YES
nfsd_flags="-tun 4"
mountd_flags=""
nfs_client=YES
nfsiod_flags="-tun 4"
# end of example
After making the above changes, reboot your system and then your
should be ready to bootserve VAX clients.
6.2. Automating The Bootserver under OpenBSD
OpenBSD is strikingly similar in layout to NetBSD, but then OpenBSD
borrows heavily from its roots in NetBSD. There was one major
difference, instead of configuring /etc/rc.conf, under OpenBSD you
must directly configure a file named /etc/netstart.
Examine the well commented /etc/netstart file on your OpenBSD system
paying special attention to the lines near the beginning of the file.
# example lines from /etc/netstart and how they should be set:
rarpd_flags="-a"
bootparamd_flags=""
nfs_server=YES
# end of example
With OpenBSD, you still have to perform a bit of your own script work
to get the MOP server running, but it's a one time thing. Edit the
/etc/rc.local file to contain the following conditional statement just
before the end of the file:
# code for starting the MOP server at boot time.
if [ -f /usr/sbin/mopd ]; then
echo -n ' mopd'; /usr/sbin/mopd -a
fi
# end of code
After modifying the items above, reboot your system and then you
should be ready to bootserve VAX clients.
6.3. Automating The Bootserver under Linux
Linux requires a bit more work than the other operating systems, but
I've put together some helper scripts for making the process simpler.
The scripts are available from my web page at the following link:
<http://world.std.com/~bdc/projects/vaxen/netboot/linux-nb.tar.gz>
I've also included the text of the scripts at the end of this guide in
``Appendix B'' for people who don't have access to the web.
There are three scripts you will need: areths.csh, vaxboot-sysv.sh,
and vaxboot-bsd.sh.
The areths.csh script is sort of like a poor man's rarpd for Linux.
The script reads in the contents of your /etc/ethers file and loads
the ARP cache and RARP tables with the appropriate information.
The vaxboot scripts are for automatically calling the areths.csh
script and running the rpc.bootparamd and mopd daemons during the
system boot. The vaxboot-sysv.sh is for the SysV style init used by
the RedHat distribution. The vaxboot-bsd.sh is for the BSD style init
used by the Slackware distribution. In fact you can use vaxboot-
bsd.sh with RedHat as well, if you call it from the /etc/rc.d/rc.local
script. RedHat caters to both styles of system initializations.
I would like to take this opportunity to say that I think
that all the Linux distributions I've worked with have
really weird init setups.
First, copy the areths.csh script to /usr/local/sbin. BTW, the
scripts are all written in mind with the various bootserver components
living in /usr/local/sbin. You'll have to edit the scripts if you've
placed the components elsewhere.
# mkdir -p /usr/local/sbin
# cp areths.csh /usr/local/sbin
# chmod a+x /usr/local/sbin/areths.csh
Configuring for RedHat (SysV Style init)
Under RedHat Linux, copy the file vaxboot-sysv.sh to the directory
/etc/rc.d/init.d and set its execute permissions.
# cp vaxboot-sysv.sh /etc/rc.d/init.d
# chmod a+x /etc/rc.d/init.d/vaxboot-sysv.sh
Next you'll need to setup some links in the runlevel directories so
the booting system knows what to do with the script when entering
certain runlevels.
# ln -s /etc/rc.d/init.d/vaxboot-sysv.sh /etc/rc.d/rc1.d/K07vaxboot-sysv
# ln -s /etc/rc.d/init.d/vaxboot-sysv.sh /etc/rc.d/rc2.d/S99vaxboot-sysv
# ln -s /etc/rc.d/init.d/vaxboot-sysv.sh /etc/rc.d/rc3.d/S99vaxboot-sysv
RedHat runs the NFS server components by default, so you need not
worry about setting up anything for them. At this point reboot your
machine, and everything should be in order to netboot your VAX client.
Configuring for Slackware (BSD Style init)
Under Slackware Linux, copy the file vaxboot-bsd.sh to the directory
/usr/local/etc.
# mkdir -p /usr/local/etc
# cp vaxboot-bsd.sh /usr/local/etc
# chmod a+x /usr/local/etc/vaxboot-bsd.sh
Ummm, it's been a while since I've run Slackware, but if I remember
correctly there's a file either named /etc/rc.local or maybe
/etc/rc.d/rc.local which is specifically for user customizations.
Anyway, find that rc.local file and add the following lines to the end
of that file:
# example additions to rc.local file under Linux
# Start the bootserver
/usr/local/etc/vaxboot-bsd.sh
# end of example
Again, resorting to vague and fuzzy recollections of my Slackware
days. I'm fairly sure that you needed to uncomment certain sections of
the configuration files for Slackware, as the NFS servers were not run
by default. I'm thinking of files named rc.inet1 and rc.inet2 but
I'll leave figuring out the details as an exercise for the reader.
Reboot your machine, and everything should be in order to netboot your
VAX client (assuming you get NFS running).
(I haven't actually tested this under Slackware. I'm only pretending
that I know it works).
6.4. Automating The Bootserver under FreeBSD
Not written yet!
6.5. More on MOP (or Look Mom, No Hands!)
There's one more very useful thing you can do to make your MOP
configuration much simpler... Reflect back to many pages before the
current section to section on ``setting up the MOP images''. Times
were simpler, and you were happily linking the file boot.mopformat to
MOPBOOT.SYS, carefully noting that the link name must be capitalized.
Well, much like the simpler times of your childhood, you were lied to.
There is no Santa Claus, and not all file names must be capitalized.
But I digress.
Going back into the /tftpboot/mop directory. If you create a link to
the boot.mopformat file with your VAX client's ethernet address as its
name, you can then boot your VAXstation from the console without
specifying the `/100' parameter. Better yet it doesn't prompt you for
the name of the bootloader. The VAX automatically grabs whatever file
is associated with the ethernet address named file.
# cd /tftpboot/mop
# ln -s boot.mopformat 08002b1659bb.SYS
You will note the lower case letters used in the ethernet address
name. In this case if you don't use the lower case letters, the MOP
server will not acknowledge the filename as containing valid
representation of the ethernet address. You must use the lower case
form of the letters.
You can even take things one step further. At least on the VAXstation
3100's (and maybe others) you can set the default boot device to be
the ethernet device.
From the VAXstation console prompt, type the following:
>>> set boot esa0
The next time you power on the VAXstation, it will try to boot from
the ESA0 ethernet device. This in turn MOP loads the bootloader from
your bootserver. Oooooh ahhhh, impress your friends.
7. Something Went Wrong
I've only got a few failing scenarios to offer up at this point. The
whole netboot procedure has been rather kind to me. Of course the
advice I'd received throughout the entire process may have had a good
deal to do with the success I've had.
7.1. Bootloader Fails to Load The Kernel
In my experience. The bootparamd responses to `whoami' requests don't
always take hold. The bootloader makes four attempts to grab a
response, but occasionally that's not enough and the boot attempt
fails.
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
whoami got question for 10.3.250.5
This is host vaxclient.test.net
Returning vaxclient (none) 127.0.0.1
whoami got question for 10.3.250.5
This is host vaxclient.test.net
Returning vaxclient (none) 127.0.0.1
whoami got question for 10.3.250.5
This is host vaxclient.test.net
Returning vaxclient (none) 127.0.0.1
From the VAX client console:
-ESA0
>> NetBSD/vax boot [980110 22:29] <<
: /netbsd
boot: client IP address: 10.3.250.5
bootparamd: 'whoami' call failed
Unknown error: code 60
: /netbsd
netboot: no interfaces left untried
rtt
Sending a `break' will drop you back to the console prompt ">>>" from
which you can start the boot process over.
This was a problem under Linux bootservers and was related to the
difficulties with Linux's support of RARP. The workaround was to load
the ARP cache with values prior to loading the RARP table.
7.2. Boot Hangs - output buffer busy
If your attempts to netboot your VAX are met with the message le0:
output buffer busy, then this section is for you.
From the VAX client console:
-ESA0
>> NetBSD/vax boot [980110 22:29] <<
: /netbsd
le0: transmit timeout, stat=0x13
le0: output buffer busy
le0: output buffer busy
le0: output buffer busy
le0: output buffer busy
The problem occurs on the netboot supported VAX systems which are
configured with more than 16Megs of memory. The reason for this is
that the memory areas critical to the operation of the lance ethernet
device get mapped in such a way that memory configurations of more
than 16Megs confuse NetBSD's interaction with the lance device. The
problem should be fixed in the future.
There's a very simple workaround for this in the meantime. It is to
pull out enough memory boards to place your system's main memory at or
below the 16Meg mark.
7.3. Boot Hangs - kernel stops, but I can ping client
Didn't I tell you that you had to use a serial console? This is what
happens when you try to boot NetBSD/vax without a serial console. As
soon as the kernel starts running, you lose output to the display
console. The kernel continues along on its merry way. You just can't
see the messages it's giving you and you can't send any input to the
system from the VAX client keyboard.
-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
You can in fact actually use a system without a serial console as long
as you've got it to a state where it boots right up into multi-user
mode. Then if the networking is set up properly on the machine, you
can telnet into the VAX from another system on your network. If at
all possible, I would still recommend having access to a serial
console. It's a bit more straightforward to deal with if something
goes wrong with your VAX.
8.
APPENDIX A - Obtaining Your Hardware Ethernet Address
When at the console prompt on your VAX client, entering the following
commands will output the ethernet address for the on board ethernet
adapter.
A.1 Obtaining The Ethernet Address of Your MicroVAX 2000 or VAXstation
2000.
>>> test 50
This will print out quite a few lines of information. The line
starting with "ID" is the one that references the VAX's ethernet
address.
ID 08-00-2B-16-59-BB
A.2 Obtaining The Ethernet Address of Your MicroVAX 3100, VAXstation
3100, or VAXserver 3100.
>>> show ether
ID 08-00-2B-16-59-BB
9. APPENDIX B - Scripts for Linux
--- areths.csh ---
#!/bin/csh
# areths.csh -- A very brain-dead script for initializing a Linux system's
# ARP and RARP tables.
#
# /etc/ethers entries must be in the format
# <hw ethernet address> <hostname>
# Examples:
#
# aa:bb:cc:dd:0e:0f hostname1
#
# is also equivalent to
#
# aa:bb:cc:dd:e:f hostname1
#
# Any other format or extraneous information for /etc/ethers will confuse and
# break the script. Don't even bother trying as it would be too easy.
# specify arp and rarp commands to use
set arp = /sbin/arp
set rarp = /sbin/rarp
# get /etc/ethers contents, ignore comment lines
set etherlist = `grep -v "^#" /etc/ethers`
set i = 1
while ( $i < $#etherlist )
set eaddr = $etherlist[$i]
@ i += 1
set hname = $etherlist[$i]
@ i += 1
$arp -s $hname $eaddr
$rarp -s $hname $eaddr
end
# end of areths.csh
--- vaxboot-sysv.sh ---
#!/bin/sh
#
# vaxboot-sysv.sh VAX bootserver components
# Author: Brian Chase, <bdc@world.std.com>
#
# See how we were called.
case "$1" in
start)
echo "Starting VAX bootserver..."
/usr/local/sbin/areths.csh &
/usr/local/sbin/mopd -a
/usr/local/sbin/bootparamd
;;
stop)
echo "Shutting down VAX bootserver..."
/usr/bin/killall bootparamd
/usr/bin/killall mopd
;;
*)
echo "Usage: $0 {start|stop}"
exit 1
esac
exit 0
# end of vaxboot-sysv.sh
--- vaxboot-bsd.sh ---
#!/bin/sh
#
# vaxboot-bsd.sh VAX bootserver components
# Author: Brian Chase, <bdc@world.std.com>
#
echo "Starting VAX bootserver..."
/usr/local/sbin/areths.csh &
/usr/local/sbin/mopd -a
/usr/local/sbin/bootparamd
exit 0
# end of vaxboot-bsd.sh