Introduction, Diskless NetBSD HOW-TO

Overview

This guide is intended to aid you in setting up a diskless NetBSD workstation. If your client isn't one of the following architectures, you can stop reading now:

• alpha
• arm32
• cobalt
• hp300
• hppa
• i386
• luna68k
• macppc
• mvme68k
• next68k
• ofppc
• pmax
• shark
• sgimips
• sparc
• sparc64
• sun2
• sun3
• vax

It covers from start to finish all of the steps necessary to configure and set up the server(s) and some basic information on setting up the client.

This document only covers the steps to boot a NetBSD system from the network. It does not describe how to set up a local hard drive to boot NetBSD. That information is covered in the INSTALL notes for your platform. The procedure described here can be used to either netboot a NetBSD installer (to configure a local hard drive), or to netboot a complete NetBSD distribution on a system with no local storage.

If you are only netbooting an installer, follow the directions for your architecture until you reach the NFS-setup page. There is a link to instructions on installation tools. If your client system does not support local console and does not support serial console (such as an hp425e or iBook), then you can still netboot a working system. Follow the directions for your architecture until you reach the filesystem page. There is a link to a page describing extra steps you must perform.

This document is very long in an attempt to be thorough. If you are already comfortable with most of these concepts, you should still skim the Introduction pages. Feel free to skip this page and go straight to your platform-specific introduction page.

Each of the architectures listed above use a different proprietary scheme of loading the initial bootloader code. Here is a general overview of the netbooting process:

1. The client-specific bootloader is retrieved from the server
   • For hp300 and some hppa, rbootd loads the NetBSD bootprogram
     1. HP bootrom does a search for bootable system and takes first one found, unless there is user intervention.
     2. As part of the search for bootable systems, the bootrom sends a RMP request (HP Remote Maintenance Protocol). The rbootd server responds with the name of the bootprogram.
     3. The HP bootrom retrieves the bootprogram from the server and starts running it.
   • For alpha, some hppa, some i386, macppc, next68k, pmax or sparc64 systems, bootpd or dhcpd sets up tftp to load the NetBSD bootprogram.
     1. Manually set up the firmware (the first time) to load the bootprogram via bootp and tftp.
     2. The firmware sends a bootp/dhcp request, and gets the necessary information from the bootpd/dhcp server.
     3. The firmware uses tftp to retrieve the bootprogram from the machine which responded to the bootp/dhcp request and starts running it.
   • For shark systems, use tftp to load the netbsd a.out kernel directly.
   • For sun2, ndbootd loads the NetBSD bootprogram
     1. If your machine is truly diskless, the firmware will always attempt to load the bootprogram via Network Disk (ND, served by ndbootd). Otherwise, you must explicitly break into the monitor and issue the netboot command each time.
     2. The firmware uses ND to retrieve the bootprogram from the machine which responded to the ND request and starts running it.
   • For sparc and sun3, rarpd sets up tftp to load the NetBSD bootprogram
     1. Manually set up the firmware (the first time) to load the bootprogram via tftp.
     2. The firmware sends a rarp request, and gets the necessary information from the rarp server.
     3. The firmware uses tftp to retrieve the bootprogram from the machine which responded to the rarp request and starts running it.
   • For vax, mop downloads the NetBSD bootprogram
     1. Manually set up the firmware to load the bootprogram via mop.
     2. The firmware sends a mop request, and gets the necessary information from the mop server.
     3. The firmware uses mop to retrieve the bootprogram from the machine which responded to the mop request and starts running it.
2. The bootloader gets the kernel from the server.

   There are four schemes used by the various platforms at this stage.

   • rarpd, bootparamd, and nfsd,
     
     1. The NetBSD bootprogram sends out a RARP request (Reverse ARP (Address Resolution Protocol)) to determine its IP address. The server sends a RARP response mapping the ethernet hardware address to an IP address.
     2. The NetBSD bootprogram then broadcasts a RPC/BOOTPARAMS/WHOAMI request to the server asking for the client name and IP address.
     3. The NetBSD bootprogram then requests a RPC/BOOTPARAMS/GETFILE to determine the nfs server and root directory, using the client name specified in the RPC/BOOTPARAMS/WHOAMI request.
     4. The NetBSD bootprogram mounts the root directory from the nfs server.
     5. The NetBSD bootprogram loads the specified kernel using NFS read calls
     6. The NetBSD bootprogram then transfers control to the kernel.
   • bootp and tftp,
     
     1. The NetBSD bootloader sends out a bootp request to determine various bits of information, namely its IP address, subnet mask, TFTP server, kernel name, and NFS path.
     2. The NetBSD bootprogram then connects to the TFTP server and downloads the kernel.
     3. The NetBSD bootprogram then transfers control to the kernel.
   • dhcp and tftp,
     
     1. The NetBSD bootloader sends out a dhcp request to determine various bits of information, namely its IP address, subnet mask, TFTP server, kernel name, and NFS path.
     2. The NetBSD bootprogram then connects to the TFTP server and downloads the kernel.
     3. The NetBSD bootprogram then transfers control to the kernel.
   • rboot, ndbootd, and mopd
     
     1. The NetBSD bootloader uses the firmware to send out rboot, ndbootd, or mopd requests to download the kernel.
     2. The NetBSD bootprogram then transfers control to the kernel.
3. The kernel takes control and begins mounting the nfs filesystem and switches to multi-user.

   The kernel needs to repeat the work of the bootloader, since there is currently no standard method of transferring that information. This means that it will use the one of the methods above to determine its IP address and the NFS path on the NFS server.

   Typically the kernel is configured to use the same protocols as the bootloader, however, this can be configured differently when compiling a new kernel.

Server hardware/OS requirements

The server must have ethernet support and enough disk space to store the necessary files for an installation of NetBSD. See your platform's INSTALL guide for details on which packages are necessary and how much space they require.

If the server has the same architecture (e.g. Motorola 680X0 microprocessor for NetBSD/hp300 and next68k, Sparc microprocessor for NetBSD/sparc, and Vax microprocessor for NetBSD/vax), and is running NetBSD, then the client will be able to use the /usr directory structure from the server, saving a significant amount of disk space.

If the server is the same port (not just the same microprocessor), then you can set up a pseudo-clustered environment where almost everything is shared between the client(s) and the server.

It is worth noting, that each stage of the netbooting process can be handled by a different server, running a different OS. This means, you can use HP-UX to handle the rbootd requests (e.g. for NetBSD/hp300), SunOS to respond to the rarp and bootparams request, and NeXTSTEP to deal with the nfs filesystem. This lends quite a bit of flexibility to the process, and is the reason these pages are broken up by daemon and not by OS.

Platform/daemon chart

Here's a quick and dirty breakdown of which client architectures require which daemons to be running on the server.

Platform\daemon	rbootd	mopd	ndbootd	rarpd	bootparamd	bootpd (1)	dhcpd (1)	tftpd	nfsd
alpha	no	no	no	no	no	yes	no	yes	yes
hp300	yes	no	no	yes	yes	no	no	no	yes
hppa	yes (2)	no	no	no	no	yes	no	yes (2)	yes
i386	no	no	no	no	no	no	yes	yes	yes
macppc	no	no	no	no	no	yes	no	yes	yes
next68k	no	no	no	no	no	yes	no	yes	yes
pmax	no	no	no	no	no	yes	no	yes	yes
sparc	no	no	no	yes (3)	no	no	yes (3)	yes	yes
sparc64	no	no	no	yes	no	no	yes	yes	yes
sun2	no	no	yes	yes	yes	no	no	no	yes
sun3	no	no	no	yes	yes	no	no	yes	yes
vax	no	yes	no	yes	yes	yes	no	no	yes

(1) dhcpd can act as a bootpd server.
(2) newer models of hppa workstations need tftp instead of rbootd.
(3) some versions of the JavaStation don't need rarp.

Server/daemon compatibility chart

Here's a breakdown of what daemons are available on which server OSes. Unless otherwise specified, the software will work on any architecture the server OS supports (e.g. for Solaris, it is assumed to work on both sparc and i386 architecture).

There are two additional pieces of software required on the server: gzip and gnutar. Now would be a good time to get and compile gzip and gnutar if there is a (c) next to them for your server operating system in the table below. gnutar is necessary to preserve the proper uid and gid numbers when extracting the client's filesystem.

OS\daemon	rbootd	mopd	ndbootd	rarpd	bootparamd	bootp	dhcp	tftp	nfs	gzip	gnutar
NetBSD	yes	yes	yes	yes	yes	yes	yes	yes	yes	yes	yes
OpenBSD	yes	yes	yes (c)	yes	yes	yes	yes	yes	yes	yes	yes
FreeBSD	yes (c)	yes (c)	yes (c)	yes	yes	yes	yes	yes	yes	yes	yes (c)
Mac OS X/Darwin	yes	no	no	yes (?)	yes	yes (2)	yes (c)	yes	yes	yes	yes (3)
Linux	yes (c)	yes (c)	no	yes (k)	yes (c)	yes	yes (c)	yes	yes	yes	yes (c)
SunOS 4	yes (c)	no	no	yes	yes	yes (c)	yes (c)	yes	yes	yes (c)	yes (c)
Solaris 2	yes (c)	no	no	yes	yes (1)	yes (c)	yes	yes	yes	yes (c)	yes (c)
NEWS-OS 4.x	yes (c)	no	no	yes	yes	yes	no	yes	yes	yes (c)	yes (c)
NEXTSTEP 3.3	no	no	no	yes (?)	yes (?)	yes (?)	yes (c)	yes	yes	yes (c)	yes (c)
HP-UX 7, 9	yes (c)	no	no	no	no	no	no	yes	yes (k)	yes (c)	yes (c)
HP-UX 10	yes (c)	no	no	yes	no	yes	yes	yes	yes	yes	yes (c)
DomainOS	no	no	no	no	no	?	?	?	no	yes (c)	yes (c)

(1) means that Solaris has bootparamd, but it doesn't interact well with the NetBSD bootloader, but there is a workaround
(2) Mac OS X and Darwin have a native bootpd, but it is unable to netboot NetBSD systems
(3) Mac OS X and Darwin have gnutar and old tar -- make sure you run gnutar to extract the files
(c) means you have to compile the program from sources
(k) means you have to compile a new kernel and reboot
(?) means there is a native version of this daemon, but its functionality is unknown

Network Configuration

There are three types of ethernet media you'll need to know about. Each type has several names, so to make things clear:

Names	Description
10Base2, Thin LAN, Thin net, Coax	Daisy-chained connection of coaxial cables with BNC connectors. Each end of the chain must have a 50 Ohm terminator, and machines in the middle of the chain use a Tee to connect.
10Base5, Thick, AUI	Daisy-chain/Star configuration (i.e. every workstation connects either to the backbone or to a "fan out" box which is connected to the backbone) using DB 15 connectors (D shaped connectors with 15 pins). The actual topology of a Thick network can be rather complicated. Most importantly, can purchase for about US$30 a transceiver that will allow you to plug a Thick connector into other types of ethernet (including Thin, 10BaseT, FDDI, and several others).
10BaseT, UTP, Twisted Pair	Star configuration, using RJ45 connectors (like US phone jack, except with more pins). You may also run across 10Base-T "T"s, such that workstations might be daisy-chained.

Now that that's settled, you'll need to make sure that your client is connected to the same subnet as the server. In other words, it absolutely must not go through a router. Connection through a hub or switch will cause no problems. If you are unsure of this, contact your network administrator. The exception to this is that the nfs server does not need to be on the same subnet.

Some things to note:

• Many 10BaseT hubs have Thin and Thick ethernet connectors on them. If this is the case with a hub near your workstation, you can probably connect to the network here.

• If your client has Thick ethernet, you can purchase, for about US$30, a transceiver that will connect you to a 10BaseT network.

• If your server has more than one type of ethernet on a card, it will only be able to use one of those ports at a time (e.g. a PCI ethernet card for Mac or Intel hardware often has 10Base-T and AUI, but only one can be used at a time). See below.

Changing ethernet media on your server

You may need to change the ethernet media on your server's ethernet card, if your network connection is wrong (i.e. it's using the wrong ethernet media type). This is briefly how to do it. More detail can be found in the documentation that came with your ethernet card (or with your computer if the ethernet is built-in). If you are uncomfortable with these procedures, ask your network administrator for help. Briefly, what's involved is:

• Many new ethernet cards or built-in ethernet (for Mac or Intel hardware) will automatically use 10Base-T if there is a 10Base-T cable plugged in. Simply unplug the 10Base-T cable and reboot to see if it defaults to the other ethernet media type.

• If that fails, your ethernet card may have come with a floppy disk with a utility program that will change the media. For Intel machines, you may need to boot off that floppy. You can also probably download the utility program from the vendor's website.

• If that fails, you will need to open your computer up and find the ethernet card. Be sure to use proper static-prevention measures, you could fry your computer. If you aren't comfortable with this, ask a friend who is comfortable to help you. There will probably be jumpers that you need to move around. Typically, either the jumper positions will be clearly labeled or will correspond to the port (i.e. if the 10Base-T is on the left, selecting the left jumper position will select 10Base-T).

Alternatively, if your server has a second ethernet card, you can create your own private network, consisting of the server and your client. Information on how to configure the server OS to give your client access to the internet is beyond the scope of this HOW-TO.

Before starting

Here are the naming conventions used in this HOW-TO, you will probably want to use your own names and addresses when following the instructions:

le0	device name of the ethernet interface (common on sun, HP, and DEC hardware)
192.168.1.10	IP address (decimal) of the diskless client.
client.test.net	Internet canonical name of the diskless client.
C0A8010A	IP address (hexadecimal) of the diskless client. Only used for SunOS, Solaris, and the sun-rbootd daemon.
CCCCCCCCCCCC CC:CC:CC:CC:CC:CC	Ethernet hardware address of the diskless client.
192.168.1.5	IP address (decimal) of the diskless server.
rbootdserver.test.net	Internet canonical name of the diskless rbootd server. (hp300 only)
mopserver.test.net	Internet canonical name of the diskless mop server. (vax only)
SSSSSSSSSSSS SS:SS:SS:SS:SS:SS	Ethernet hardware address of the bootloader server.
tftpserver.test.net	Internet canonical name of the diskless tftp server.
rarpserver.test.net	Internet canonical name of the diskless rarp server.
bootparamserver.test.net	Internet canonical name of the diskless bootparams server.
bootpserver.test.net	Internet canonical name of the diskless bootp server.
dhcpserver.test.net	Internet canonical name of the diskless dhcp server.
nfsserver.test.net	Internet canonical name of the diskless nfs server.
/export/client/root	Path to client's filesystem, as specified on the nfsserver.
dns.test.net	Internet canonical name of the domain name server (DNS).
router.test.net	Internet canonical name of the router for the client's subnet.
255.255.255.0	Subnet mask used by the client (may be set with bootpd and dhcpd).
192.168.1.255	Broadcast address used by the client (may be set with bootpd and dhcpd).

Here are few things worth noting:

• You don't need to run all of the daemons on one server, they may each be handled by a different server. There are various reasons you may want to do this (e.g. using HP-UX for rbootd and some other platform for the rest). This is why the names of the servers are distinguished throughout this HOW-TO. If you plan to run all of your daemons on one machine, then simply equate the names, e.g. for a hp300 diskless server:
  rbootdserver = rarpserver = bootparamserver = nfsserver.

• If the attempt to boot the client fails at any stage, the wisest move is to reset the client. I've seen some weird things happen on the second try.

  For hp300 machines, this is accomplished by hitting Shift-Reset, pressing the reset button on a Series 400 workstation, or power-cycling a Series 300 workstation.

• And lastly, a recommendation: Each daemon can be set up and tested one at a time. This helps narrow down where a problem may be, as you can be sure that the previous step worked. So, it is probably best if you set up the client-specific bootloader daemon, test to see that it worked, then move on to rarp (unless rarp is your client-specific bootloader daemon). Make sure that rarp and the client-specific bootloader daemon work, then set up bootparamd, and so on. Once you're sure that everything works (i.e. the kernel starts loading), then you should go about setting up the daemons to start automatically and installing the necessary diskless filesystem.

Download NetBSD

OK, now make some room on your server -- it's time to download NetBSD. It is best to do this from an actual ftp program and not a browser, since you can download multiple items at once. See the NetBSD Formal Releases for the most current version of NetBSD.

1. # mkdir -p /export/client/NetBSD-release/installation/misc

2. # mkdir -p /export/client/NetBSD-release/binary/security
   Note, you may not perform this step if you don't meet the requirements for US Export Control

3. # mkdir -p /export/client/NetBSD-release/binary/sets

4. # cd /export/client/NetBSD-release

5. # ftp ftp.NetBSD.org
   Replace ftp.NetBSD.org with the nearest ftp mirror

6. ftp> bin

7. ftp> prompt

8. ftp> cd /pub/NetBSD/NetBSD-release/<client-arch>/

9. ftp> mget *
   This should download everything, including files in subdirectories. If the ftp program on your server doesn't download subdirectories, you will need to manually cd and lcd to the directories and mget everything.

   If your server doesn't have enough space for everything, fear not. All you really need to get a minimally functional NetBSD is (starting from /pub/NetBSD/NetBSD-release/<client-arch>/):

   INSTALL.txt
   binary/sets/kern.tgz
   binary/sets/base.tgz
   binary/sets/etc.tgz
   installation/misc/SYS_UBOOT.gz (for hp300)
   installation/misc/rbootd.tgz  (for hp300)
   

10. ftp> exit

11. Please take the time to read the official INSTALL notes, located in /export/client/NetBSD-release/INSTALL

Platform-specific Introduction

Now, read the introduction with details on your client's platform:

• alpha
• arm32 (coming soon)
• cobalt (see the FAQ)
• hp300
• hppa
• i386
• luna68k (see the Installation notes)
• macppc
• mvme68k (coming soon)
• next68k
• ofppc (coming soon)
• pmax
• sgimips (see the FAQ)
• shark
• sparc
• sparc64
• sun2
• sun3
• vax
• Alternatively, you may have a local bootloader and run diskless otherwise.

Home Page

Documentation top level