Introduction (alpha-specific), Diskless NetBSD HOW-TO

Client hardware requirements

Any Alpha machine running SRM console can be netbooted. The only Ethernet device the console on most Alpha systems knows how to boot from is the onboard Ethernet interface or a DEC Tulip (21040, 21041, 21140) based PCI Ethernet card. <cjs@NetBSD.org> tested an older SMC 100 Mbps card that uses this chip and it works fine. Many older systems will not be able to use the newer 2.0 stepping of the 21140, however. If your system appears not to be receiving packets, this may be the problem.

Setting up the client hardware

• Installing the latest SRM for your alpha 3000

  You can find the latest bootable SRM for your alpha 3000 at http://ftp.digital.com/pub/DEC/Alpha/firmware/readmes/archive/dec3000.html.

• Selecting the correct ethernet media

  The Alpha console defaults to using the first Tulip-based ethernet interface on the system. (The command show device will give a list of installed devices that the console knows about).

• Determining your ethernet hardware address

  You will need to determine the ethernet hardware address of your workstation. This is sometimes also known as the "link level address" or MAC. It is a twelve digit hexadecimal number (i.e. it uses 0-9 and A-F for each digit). For example, 08:00:09:09:45:84 is the ethernet address of my workstation.

  <cjs@NetBSD.org> noticed that on his AXPpci33 with an SMC PCI 21140-based Ethernet card, the console choose its own Ethernet address rather than using the one in the ROM on the card. NetBSD uses the one in the card ROM, however. He got around this with a bootptab entry for the system itself and two separate entries, each with a different hardware address, that included the main entry as such:

  #/etc/bootptab
  client.test.net.master:\
          :ht=ether:\
          :sm=255.255.255.0:\
          :lg=192.168.1.5:\
          :ip=192.168.1.10:\
          :hn:\
          :bf=boot.netbsd:\
          :bs=auto:\
          :rp=/export/client/root/:\
          :vm=rfc1048:\
  	:tc=.test:
  client.test.net:ha=CCCCCCCCCCC1:tc=client.test.net.master:
  client.test.net:ha=CCCCCCCCCCC2:tc=client.test.net.master:
  

  Where CCCCCCCCCCC1 is the address of the on-board ethernet and CCCCCCCCCCC2 is the address of the ethernet card being used to netboot from.

• Netbooting once

  Press ^C during the bootup procedure to get to the console prompt. This has to be done before the first stage loader is loaded from the disk or the second stage tftp'd from the network.

  The typical command line to boot into multi-user mode via the network would be:

          boot -flags 'a' ewa0
  

  This tells the console to use the interface ewa0, which is the first Tulip-based Ethernet interface on the system. (The command show device will give a list of installed devices that the console knows about.) It uses TFTP to load the file specified in the bootptab file on the server and then executes it, passing the a flag to it. This flag is later passed to the kernel instructing it to do an automatic boot, i.e. boot straight into multi-user mode.

• Making diskless operation the default

  Press ^C during the bootup procedure to get to the console prompt. This has to be done before the first stage loader is loaded from the disk or the second stage tftp'd from the network.

  There are certain console variables you can set so that you don't need to give so many parameters to the boot command, and so that your system can automatically boot when powered up or reset. A few of them are listed below. (For a full explanation, see page 2-26 et seq. in the Alpha AXP Architecture Reference Manual.) The variables are set with the command set variable_name value and shown with show variable_name. You can also use wildcards with the show command, as in show boot*.

  AUTO_ACTION	This determines the console action following an error halt (e.g., operating system panic) or powerup. It may be set to BOOT or HALT.
  BOOTDEF_DEV	This is an ordered list of devices (separated by commas, no spaces) that the system tries to boot from if the boot command is given without parameters, or if an AUTO_ACTION boot is in progress.
  BOOT_FILE	The file to boot if no -file argument was given to the boot command or if the system is doing an AUTO_ACTION boot.
  BOOT_OSFLAGS	The flags to pass to the kernel (separated by commas) if no -flags argument was given to the boot command or if the system is doing an AUTO_ACTION boot. Typical flags would be a for a multi-user (automatic) boot (as opposed to dropping into single user mode) and n to prompt for the root device after probing all devices.
  BOOT_RESET	If OFF only a warm boot is performed on a system halt or boot command; if ON a full reset (cold boot) is performed.
  CONSOLE	The console device; may be graphics or serial.
  EWA0_PROTOCOLS	The protocol(s) used by the ewa0 (tulip Ethernet) device for booting. May be BOOTP or MOP. Use BOOTP for NetBSD.

  The console uses the BOOTP TFTP server address (sa) attribute to determine which server it loads the second stage bootstrap from.

  Note that there is a -file filename parameter that can be added to the boot command line, but the behaviour of is somewhat different between booting from disk and booting over the network. When booting from disk, the -file parameter is passed to the NetBSD second stage bootstrap, which uses it to determine which kernel to load. When booting from the network, the console itself uses the -file parameter to determine which file to retrieve via TFTP. (The file retrieved via TFTP is the NetBSD second-stage bootstrap.) If no filename is specified via the file parameter or the BOOT_FILE console variable, the `bootfile' (bf) BOOTP attribute is used.

  This means, unfortunately, that there is no way to specify which kernel will be loaded from the NFS root partition.

How the bootrom starts loading from a diskless server

Booting and running NetBSD/alpha over a network requires a BOOTP server, a TFTP server and an NFS server. (These are usually all run on the same machine.) There are three basic stages to the boot:

1. The Alpha console software sends a BOOTP request to get its own address, the address of the TFTP server and the file to download. It downloads this file, which is the second stage bootstrap, via TFTP and then executes it.

2. The second stage bootstrap uses further information in the BOOTP packet that the console received to find the NFS server and path and retrieve the kernel (the file /netbsd). After loading the kernel into memory, it executes it.

3. The kernel probes and configures the devices, and then sends out another BOOTP request so it can find out its address, the NFS server, and path. (The kernel probably should get this information from the console, but it currently doesn't.) It then mounts its root via NFS and continues.

A few things worth noting

• As noted above, there is no way to specify the name of the kernel being loaded, though the second stage bootloader will look for different files if netbsd isn't available.

• As noted above, the bootp request sent will use the MAC address of the built-in ethernet, not the MAC of any ethernet cards installed.

Using BOOTP with old Alphas

On some, mostly older, Alphas, you must force the use of RFC1048-style BOOTP replies.

To do this, use vm=rfc1048 instead of vm=auto in the bootpdtab entry. If you use dhcpd(8), enable the always-reply-rfc1048 and use-host-decl-names options.

Begin setting up your bootloader

Get installation/netboot/netboot from the NetBSD distribution. This is what is sent by TFTP. Copy this file to an appropriately named file in /tftpboot, such as boot.netbsd.alpha.

1. bootpd
2. tftpd
3. nfs
4. client filesystem
5. finishing up

Home Page

Documentation top level