Netbooting IBM pSeries & RS/6000

Table of contents

• Introduction
• Netboot Client
  • Selecting the Boot Device
  • Finding the Hardware (MAC) Address
  • Tips for the Netboot Client
• Netboot Server
  • dhcpd (bootp)
  • tftp
  • Tips for the Netboot Server

Netbooting is very convenient for developers who need to test kernels very quickly (ie "does it boot? how about now?"). The simplest netboot method just transfers the Linux kernel (zImage) over the network. It is also possible but not at all necessary to NFS mount the root filesystem. (For information on diskless booting, please see the penguinppc.org mini-HOWTO.)

Netbooting yaboot is not possible, because the firmware is unable to request files of a specific name (eg yaboot.conf) from the tftp server. It simply re-sends a BOOTP request, followed by re-requesting the yaboot binary, and then tries to interpret that as a yaboot.conf file.

To netboot, you will need 2 machines - one is the netboot server and the other is the victim. You will need their network interfaces connected, either via a crossover cable or on the same subnet. I have only tried netbooting via ethernet, but I assume tokenring works as well. The victim will need an installed Linux partition, and the server will need the kernel with which to boot the victim.

Netbooting works in two stages. First, the firmware broadcasts a bootp request (from the specified interface) to determine the IP address, tftp server, and tftp file it should use. It then configures the interface to use that IP, and requests the file from the tftp server. Once the file (the Linux kernel) has downloaded, the firmware runs it (just as it runs a kernel from the PPC Boot partition).

Before you start, make sure you have the latest available firmware installed on your victim. Netbooting is a fairly advanced feature that may not be fully tested in the first firmware releases. The latest firmware for all recent machines can be found on IBM's pSeries & RS/6000 firmware page.

Selecting the Boot Device

It is possible to set up netbooting entirely from the Open Firmware prompt, but IBM's SMS (System Management Services) menus simplify the process greatly. Booting into the SMS menu (F1 while the POST icons are appearing on the monitor), select Multiboot, then Select Boot Devices, then Configure 1st Boot Device. Select the network interface you wish to netboot from.

It's important to make that network interface the only device in the boot list (although placing floppy and CD-ROM drive before it is a good idea). Netbooting can fail mysteriously, and if it does SMS will happily boot from the hard disk, which can confuse the user who expected a different kernel.

Finding the Hardware (MAC) Address

After selecting the network interface to boot from, you'll need to know its hardware address. This can be found in a few different ways, but the easiest is the SMS menu.

Return to the top level of the SMS menus. Choose Remote Initial Program Load Setup, then Adapter Parameters. This will preset a list of network interfaces in the system along with their hardware address. Find the adapter you chose to boot from and write down its hardware address.

Tips for the Netboot Client

The "Autosense" (10/100 and half/full duplex) feature on 10/100 ethernet cards can interfere with netbooting over a switch. A simple workaround is to use the SMS menu to hardcode the speed and duplex features of the card. The correct settings depend on your switch, but 100 Mbps/Full duplex works.

The Remote Initial Program Load Setup ping tool can fail. tcpdump reveals it trying to ping 0.0.0.0 and timing out when no one answers. Don't trust it.

After choosing the boot interface from the SMS menu, it may be helpful to make an OF alias for it. This will allow you to boot from OF as boot net rather than boot /pci@3fff.... To do this, find the full OF path to the ethernet device (eg let SMS set it, then printenv boot-device), then

		devalias net <full OF path>
		

After setting the net alias

		boot net root=/dev/xxx
		

In this example, 'net' persists across reboots.

The OF environment variable boot-file is used as kernel arguments if no kernel arguments were passed on the OF command line. If you wish to pass arguments at every boot with no manual intervention, you can (for example)

		setenv boot-file root=/dev/sda3
		

This is true for netbooting as well as booting from disk. (yaboot makes this trick unnecesary.)

pSeries firmware does not support broadcast BOOTP responses. Specifying a server IP address in the SMS configuration screens may work around this problem.

On the netbooting server, you will need two pieces of software installed: a bootp daemon and a tftp daemon. ISC's dhcpd (included in almost all Linux distributions) works well for bootp and has a much nicer configuration file than the traditional bootpd.

dhcpd

dhcpd answers the bootp request sent by the firmware, assigning the firmware its IP configuration and more importantly the address of the tftp server. Here is a sample dhcpd.conf:

always-reply-rfc1048 true; [compatibility with broken firmware]

deny unknown-clients;      [ignore unknown requests]
not authoritative;         [ignore unknown requests]

default-lease-time 600;    [irrelevant for the firmware]
max-lease-time 7200;       [irrelevant for the firmware]

subnet 192.168.1.0 netmask 255.255.255.0 {       [per interface]
    group {
        next-server 192.168.1.1;                 [the tftp server]

        host canis-lp1-scurry {                  [irrelevant]
            fixed-address 192.168.1.2;           [only used by firmware]
            hardware ethernet 00:02:55:90:02:f3; [client's MAC address]
            filename "zImage.canis.lp1";         [file to tftp - the kernel]
        }

        host canis-lp2-phoenix2 {
            fixed-address 192.168.1.3;
            hardware ethernet 00:06:29:dc:a0:a5;
            filename "zImage.canis.lp2";
        }

        ...
    }
}
		

tftpd

tftp is a very simple file-transfer protocol. The firmware, after being assigned an IP address and told which server to ask (by dhcpd), makes a tftp request for the kernel. tftpd, the tftp server, is typically run out of inetd:

tftp   dgram   udp   wait   nobody   /usr/sbin/tcpd   /usr/sbin/in.tftpd -s /tftpboot
		

In this case, place all tftp-able files (such as kernels) in /tftpboot. When the firmware requests "zImage.chrp-rs6k", tftpd will transmit /tftpboot/zImage.chrp-rs6k.

Tips for the Netboot Server

The tftp file transfer can be interrupted by just about anything. With large file transfers (2+ MB), you're almost certain to be interrupted by an arp request from the server. If that happens, your transfer fails and the boot fails. The error message may look like this:

		BOOTP: do-TFTP-read couldnt get block NNNN
		

where NNNN is a block number like 4391. To prevent this, use arp(8) on the server to hardcode the client into the server's arp cache:

		/sbin/arp -s 192.168.1.5 00:11:22:33:44:55
		

Remember, if you switch the interface you netboot from, you must remember to change the hardcoded MAC address too (in addition to updating dhcpd.conf)! If you don't, the bootp request will succeed but the kernel will never even begin to download via tftp.