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:
There are four schemes used by the various platforms at this stage.
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.
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.
Here's a quick and dirty breakdown of which client architectures require which daemons to be running on the server.
|hppa||yes (2)||no||no||no||no||yes||no||yes (2)||yes|
|sparc||no||no||no||yes (3)||no||no||yes (3)||yes||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.
|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
|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.|
|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
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).
|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:
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:
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.
|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.|
IP address (hexadecimal) of the diskless client.|
Only used for SunOS, Solaris, and the sun-rbootd daemon.
|Ethernet hardware address of the diskless client.|
|192.168.1.5||IP address (decimal) of the diskless server.|
Internet canonical name of the diskless rbootd server.|
Internet canonical name of the diskless mop server.|
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:
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.
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)