Net booting a diskless Sun3 from a Linux server

My system consists of a Linux server (basically Slackware-3.6 but with kernel 2.2.10 and various other irrelevant package upgrades) and 2 Sun3’s, only one of which is ever in use at any given time (thus they use the same swap partition on the server – later).

The Sun3’s are diskless and hence boot from the Linux box, and mount all filesystems from it. The Sun’s run NetBSD 1.3.2 largely because the Sun 3 port of Linux was not very stable or mature when I set things up.

OK, some basic info for future use:

Host Hostname Ethernet addr IP addr
Linux PC moriah 00:00:C0:8C:AB:2E 192.168.200.1
Sun 3/60 hermon 08:00:20:00:49:16 192.168.200.2
Sun 3/50 carmel 08:00:20:06:1f:50 192.168.200.3

The boot process for the Suns is basically as follows:

  1. tell the machine to boot from the ethernet device
  2. it gets its IP address by rarp
  3. it uses tftp to get a 2nd stage boot program **whose name is the IP address of the client** from the server
  4. the 2nd stage boot loader gets boot parameters from the bootp server
  5. the boot parameters specify where the root filesystem, containing the kernel, is located.
  6. The boot loader nfs-mounts this remote root f/s and boots the kernel.
  7. Once it has its root f/s the boot process is pretty standard as per a diskful machine.

OK, in more detail:

Power on machine, hit L1-A if necessary to get a monitor prompt

Enter boot command, specifying ethernet interface as the boot device:

> b le(0,0,0)

First thing that happens is the machine broadcasts rarp requests saying “This is my ethernet addr, can somebody tell me my IP address please”.

My linux kernel is compiled with rarp support, and the kernel rarp table is populated at boot time by the following commands in rc.local:

rarp -s hermon  08:00:20:00:49:16
rarp -s carmel  08:00:20:06:1F:50

(/etc/hosts on moriah contains entries for hermon and carmel so the names are resolvable to numeric addresses)

(the forward-mapping arp table is also set up at boot time on moriah by "arp -f /etc/ethers" command – sadly rarp has no corresponding -foption so each entry must be added individually).

On receiving a response from moriah to the rarp request, the Sun contacts the tftp server on moriah and attempts to download the file /tftpboot/<my-IP-addr> from it. /tftpboot on moriah looks like:

moriah% ls -lF /tftpboot/
total 16
lrwxrwxrwx   1 root     root            7 Aug  3 23:00 C0A8C802 -> netboot*
lrwxrwxrwx   1 root     root            7 Aug  3 23:00 C0A8C803 -> netboot*
-rwxr-xr-x   1 root     root        15360 Aug  1 22:56 netboot*

where netboot is the NetBSD stage 2 boot program. IP addresses are in hex as you can see.

The tftp server in.tftpd runs from inetd on moriah – the relevant line from /etc/inetd.conf is:

moriah% grep tftp /etc/inetd.conf
tftp    dgram   udp     wait    nobody  /usr/sbin/in.tftpd in.tftpd

and from /etc/services:

moriah% grep tftp /etc/services
tftp            69/udp

Once dowloaded, the stage 2 boot program executes: its first task is to get its boot parameters from the bootp server. I had trouble getting the bootpd program which came with Slackware to work so I replaced it with bootparamd from the NetKit. bootparamd runs as a daemon, but could just as well run from inetd. It uses the file /etc/bootparams to hold boot config information:

moriah% cat /etc/bootparams
hermon  root=moriah:/export/root/hermon swap=moriah:/export/swap
carmel  root=moriah:/export/root/carmel swap=moriah:/export/swap

All that is specified in this case is the root and swap partitions for each of the 2 Sun’s – as I said they share a swap partition as only one is ever up at any one time.

From then on it’s plain sailing (you must of course have nfs working on the server so the clients can mount the filesystems). The boot loader mounts the root fs from the server, and loads the kernel (which in the case of NetBSD must be /netbsd – I only found this out by trial and error). The root fs in my case contains everything, but there’s no reason why you shouldn’t nfs mount other filesystems in the usual way of course once the kernel boots. Here’s the contents of /export/root/hermon, FWIW:

moriah% ls -lF /export/root/hermon
total 3955
drwxr-xr-x   2 root     root         1024 Jan  5  1998 altroot/
drwxr-xr-x   2 root     root         1024 Jan  5  1998 bin/
-rw-------   1 root     root       458752 Aug 10 19:26 core
drwxr-xr-x   3 root     root         5120 Aug 17 01:35 dev/
drwxr-xr-x   8 root     root         2048 Aug 14 15:26 etc/
-rw-------   1 root     root        16656 Aug 13 15:58 getty.core
drwxr-xr-x   3 root     root         1024 Aug 13 15:55 home/
drwxr-xr-x   2 root     root         1024 Dec  6  1997 mnt/
lrwxrwxrwx   1 root     root           13 Aug 14 05:56 netbsd -> netbsd.hermon*
-rw-r--r--   1 root     root      1025115 Aug  2 21:34 netbsd-gen
-rw-r--r--   1 root     root       769619 Aug  2 21:34 netbsd-inst
-rw-r--r--   1 root     root       983596 Aug  2 21:35 netbsd-rd
-rwxr-xr-x   1 root     root       750847 Aug 14 05:56 netbsd.hermon*
drwxr-xr-x   2 root     root         1024 Aug 10 00:21 proc/
drwxr-xr-x   3 root     root         1024 Aug 10 00:03 root/
drwxr-xr-x   2 root     root         2048 Jan  5  1998 sbin/
drwxr-xr-x   2 root     root         1024 Dec 19  1997 stand/
drwxr-xr-x   2 root     root         1024 Aug 13 16:06 swap/
lrwxrwxrwx   1 root     root           11 Aug 10 00:02 sys -> usr/src/sys/
drwxrwxrwt   3 root     root         1024 Aug 17 01:18 tmp/
drwxr-xr-x  15 root     root         1024 Aug 13 15:45 usr/
drwxr-xr-x  19 root     root         1024 Dec  6  1997 var/

There’s a few old kernels lying aroud, the one in use I configured and built for this machine. The only other thing that I had trouble figuring out was how to tell the Sun to swap on the server (on another partition). Here is /export/root/hermon/etc/fstab which specifies this (in this case no other f/s are mounted as the root contains everything):

moriah% cat /export/root/hermon/etc/fstab

moriah:/export/swap none swap sw,nfsmntpt=/swap

Eddy Younger <eddy@shofar.uklinux.net>

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.