Table of Contents

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:

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:

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.

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:

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:

Table of Contents
NetBSD Home Page
NetBSD Documentation top level

(Contact us) $NetBSD: intro.html,v 1.7 2015/10/09 10:20:05 jnemeth Exp $
Copyright © 1998-2004 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.