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: 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: 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: 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: 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 #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 NetBSD/vax Kernel 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: 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: 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 # # 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, # # 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, # 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