5. The aboot Loader

5.6.1. Device Naming

This corresponds to the device from which SRM will attempt to boot. Examples include:

For example to boot from the disk at SCSI id 6, you would enter:

>>> boot dka600

To list the devices currently installed in the system type show dev at the SRM command line. In contrast to Linux device naming, the partition number on a disk device is not given as part of the device name (you may see extra numbers after the device names when running show dev - these correspond to things like PCI bus and device numbers and are not useful to the user). Remember, as mentioned in Section 2.3, that SRM knows nothing about partitions or disklabels - it merely reads a boot block and secondary bootstrap from sectors on a disk. Therefore, the partition number is given as part of the boot filename.

5.6.2. Boot Filename

The filename argument takes the form: "[n/]filename"

n is a single digit in the range 1..8 that gives the partition number from which to boot from. filename is the path of the file you want boot. For example to boot a kernel named vmlinux.gz from the second partition of SCSI device 6, you would enter:

>>> boot dka600 -file 2/vmlinux.gz

Or to boot from floppy drive 0, you'd enter:

>>> boot dva0 -file vmlinux.gz

If a disk has no partition table, aboot pretends the disk contains one ext2 partition starting at the first diskblock. This allows booting from floppy disks.

As a special case, partition number 0 is used to request booting from a disk that does not (yet) contain a file system. When specifying "partition" number 0, aboot assumes that the Linux kernel is stored right behind the aboot image. Such a layout can be achieved with the swriteboot command. For example, to setup a filesystem-less boot from /dev/sda, one could use the command:

# swriteboot /dev/sda bootlx vmlinux.gz

Booting a system in this way is not normally necessary. The reason this feature exists is to make it possible to get Linux installed on a systems that can't boot from a floppy disk (e.g., the Jensen).

5.6.3. Boot Flags

A number of bootflags can be specified. The syntax is:

-flags "options..."

Where "options..." is any combination the following options (separated by blanks). There are many more bootoptions, depending on what drivers your kernel has installed. The options listed below are therefore just examples to illustrate the general idea:

Some SRM implementations (e.g., the one for the Jensen) are handicapped and allow only short option strings (e.g., at most 8 characters). In such a case, aboot can be booted with the single-character boot flag "i". With this flag, aboot will enter interactive mode

5.6.4. Using aboot interactively

As of version 0.6, aboot supports a simple command-oriented interactive mode. Note that this is different from the prompt which previous versions issued when booted with the "i" flag, or after failing to load a kernel. You can get a summary of the available commands by typing "h" or "?" at the prompt:

>>> boot dka0 -fl i aboot> ? h, ? Display this message q Halt the system and return to SRM p 1-8 Look in partition <num> for configuration/kernel l List pre-configured kernels d <dir> List directory <dir> in current filesystem b <file> <args> Boot kernel in <file> (- for raw boot) with arguments <args> 0-9 Boot pre-configuration 0-9 (list with 'l') aboot> b 3/vmlinux.gz root=/dev/sda3 single

5.6.5. The aboot.conf configuration file

Since booting in that manner quickly becomes tedious, aboot allows to define short-hands for frequently used command lines. In particular, a single digit option (0-9) requests that aboot uses the corresponding option string stored in file /etc/aboot.conf. A sample aboot.conf is shown below:

# # aboot default configurations # 0:3/vmlinux.gz root=/dev/sda3 1:3/vmlinux.gz root=/dev/sda3 single 2:3/vmlinux.new.gz root=/dev/sda3 3:3/vmlinux root=/dev/sda3 8:- root=/dev/sda3 # fs-less boot of raw kernel 9:0/vmlinux.gz root=/dev/sda3 # fs-less boot of (compressed) ECOFF kernel -

With this configuration file, the command

>>> boot dka0 -fl 1

corresponds exactly to the boot command shown above.

Finally, at the aboot prompt, it is possible to enter one of the single character flags ("0"-"9") to get the same effect as if that flag had been specified in the boot command line. As noted in the help text cited above, you can also list the available default configurations with the "l" command.

5.7.1. DHCP & BOOTP configuation

Once those packages are installed there are a few setup issues to take care of.

Create the default directory to which files will be pulled from using tftp.

# mkdir /tftpboot

Create the dhcp.leases file which is not create per default (though it should be) when you install the dhcp package so the dhcp server may start.

# mkdir -p /var/state/dhcp
# touch /var/state/dhcp/dhcpd.leases

Configure the inetd to accept the tftp service. Edit your /etc/inetd.conf file and locate the following line. Then uncomment it and save the file.

#tftp	dgram	udp	wait	root	/usr/sbin/tcpd	in.tftpd

Create the /etc/dhcp.conf configuation file. An example config is provided below with the directives which allow BOOTP.

subnet 192.168.1.0 netmask 255.255.255.0 {
       option routers                        192.168.1.1;
       option subnet-mask                  255.255.255.0;
       option nis-domain                "alphalinux.org";
       option domain-name	        "alphalinux.org";
       option domain-name-servers            192.168.1.2;
       range                 192.168.1.3   192.168.1.254;
       range dynamic-bootp   192.168.1.3   192.168.1.254;
       default-lease-time                          21600;
       max-lease-time                              43200;
       allow bootp;
       allow booting;
       filename "/tftpboot/vmlinux.bootp";	
}                                 

# service inet restart

5.7.2. bootpd configuration

The bootpd is the older way of making a bootp server and for the most part is not used anymore in lieu of more modern DHCP servers that are capable of handling the protocol with minimal configuration and more flexibility. This style of setup does not allow just any client to be granted a BOOTP request. Instead you must specify the ip address and MAC address of the allowed clients. Naturally this could get quite tedious if you where say administrating more than a few machines.

bootpd rpms can be found on older versions of RedHat's distributions like version 5.2 and below. Note: the rpm itself is named bootp though the package does contain the bootpd filename. It is available for download at your favorite RedHat mirror. The bootp package requires the tftp-server just as before and the location to where the files are grabbed from is the same.

Once installed you must configure your inetd service to talk to the bootpd daemon. Uncomment the following line in your /etc/inetd.conf .

#bootps dgram   udp     wait    root    /usr/sbin/tcpd  bootpd

Then restart the inetd.

# service inet restart

Configuring the /etc/bootptab file. The bootptab file has one entry describing each client that is allowed to boot from the server. For example, if you want to boot the machine voodoo.alphalinux.org, then an entry of the following form would be needed:

voodoo.alphalinux.org:\ :hd=/tftpboot/:bf=vmlinux.bootp:\ :ht=ethernet:ha=08012B1C51F8:hn:vm=rfc1048:\ :ip=192.12.69.254:bs=auto:

This entry assumes that the machine's Ethernet address is 08012B1C51F8 and that its IP address is 192.12.69.254. The Ethernet address can be found with the show device command of the SRM console or, if Linux is running, with the ifconfig command. The entry also defines that if the client does not specify otherwise, the file that will be booted is vmlinux.bootp in directory /tftpboot. For more information on configuring bootpd, please refer to its man page.

5.8.1. Netboot using the kernel sources

1. Make sure the kernel you want to boot has already been built

2. Execute the following while in the linux source dir:

   • make bootimage

   • make bootpfile

   This creates a uncompressed kernel named 'bootpfile' located in arch/alpha/boot/ . Note that this kernel is significantly larger than that produced by the aboot sources.

3. Copy bootpfile to the bootp server's directory. With a default setup the tftp server would look in /tftpboot so copy bootpfile into /tftpboot .

5.8.2. Netboot using the aboot sources

1. Build aboot with with the command make netboot.

2. Make sure the kernel that you want to boot has been built already. By default, the aboot Makefile uses the kernel in /usr/src/linux/arch/alpha/boot/vmlinux.gz (edit the Makefile if you want to use a different path). The result of make netboot is a file called vmlinux.bootp which contains aboot and the Linux kernel, ready for network booting.

3. Copy vmlinux.bootp to the bootp server's directory. In the example above, you'd copy it into /tftpboot/vmlinux.bootp.

Next, power up the client machine and boot it, specifying the Ethernet adapter as the boot device. Typically, SRM calls the DEC based Ethernet adapter ewa0 and the Intel based adapter eia0, so to boot from that device, you'd use the command:

>>> boot ewa0

The -fi and -fl options can be used as usual. For example,

>>> boot ewa0 -fi bootpfile -fl "root=/dev/hda2"

In particular, you can ask aboot to prompt for Linux kernel arguments by specifying the option -fl i .

5.8.3. Updating the SRM console through BOOTP

Updating your SRM console over the network through BOOTP is just as easy as booting the Linux kernel in the same manner. The hardware prerequisites are the same as netbooting Linux.

First you have to obtain an SRM image that is able to BOOTP over the network. These images normally have a .exe extension. For DEC/Compaq Alpha products these images can be found at ftp://gatekeeper.dec.com/pub/DEC/Alpha/firmware/v5.8/. You can also find these files on the Alpha Systems Firmware Update CD-ROM. API NetWorks does not offer net bootable SRM images at this time though that may change in the near future.

For example say you had a DS20 and wanted to update it's firmware over the network using BOOTP. You would have to,

1. Get the correct firmware image for the DS20 that supported BOOTP execution which in this case the filename is ds20_v5_8.exe from ftp://gatekeeper.dec.com/pub/DEC/Alpha/firmware/v5.8/.

2. Copy the file to the /tftpboot folder located on the BOOTP server.

To execute the update from SRM you would do the following:

>>> b ewa0 -fi ds20_v5_8.exe

SRM would then proceed to upgrade the firmware in the same fashion as if you had done the firmware update from a CD.

5.9.1. What is a disklabel?

A disk label is a partition table. Unfortunately, there are several formats the partition table can take, depending on the operating system.

DOS partition tables are the standard used by Linux and Windows. AlphaBIOS systems and every Linux kernel can read DOS partition tables. Unfortunately, the SRM console's boot sector format overlaps with parts of the DOS partition table on disk, and therefore DOS partition tables cannot be used with SRM.

BSD disklabels are used by several variants of Unix, including Tru64. SRM's boot block does not conflict with the BSD disklabel (in fact, the BSD disklabel resides entirely within "reserved" areas of the first sector), and Linux can use a BSD disklabel, provided that support for BSD disklabels has been compiled into the kernel.

To boot from a disk using SRM, a BSD disklabel is required. If the disk is not a boot disk, the BSD disklabel is not required. A BSD disklabel can be created using fdisk, the standard Linux disk partitioning tool.

5.9.2. Partitioning the Easy Way: a DOS Disklabel

The simplest way to partition your disk is to let your Linux installer do it for you, for example by using Red Hat's disk druid or fdisk. On Red Hat 6.1, this will produce a valid BSD disklabel, but only if the disk in question previously contained one. In most cases, this will produce a DOS disklabel. It will be readable by Linux, but you will not be able to boot from it via SRM. For this reason, you will probably want to create a BSD disklabel manually in order to boot Linux

5.9.3. Partitioning with a BSD Disklabel

1. Start fdisk on the disk you're configuring

2. Choose to make a BSD disklabel - option 'b' (newer versions of fdisk will detect existing BSD disklabels and automatically enter disklabel mode)

3. You'll notice some things: Partitions are letters instead of numbers, from a-h Partition 'c' covers the whole of the disk. This is the convention, don't touch it. While you can see it, note down the disk parameters as you'll use them more often than with the DOS-disklabel approach

4. Creating a new partition uses the same procedure as the DOS-disklabel approach, except that the partitions are referred to by letter instead of number. That is, 'n' to make a new partition followed by the partition letter followed by the starting block followed by the end block

5. Setting partition type is slightly different, because the numbering scheme is different (1 is swap, 8 is ext2).

6. When you are finished, write ('w') and quit ('q') as normal.

There are some important catches that you must be aware of when partitioning using a BSD disklabel:

• Partition 'a' should start about 1M into the disk: don't start it at sector 1, try starting at sector 10 (for example). This leaves plenty of space for writing the boot block (see below)

• There is a bug in some versions of fdisk which makes the disk look one sector bigger than it actually is. The listing when you create the BSD disklabel is correct. The last sector of partition 'c' is correct. The default last sector when creating a new partition is 1 sector too big

• Always adjust for this extra sector. This bug exists in the version of fdisk shipped with Red Hat 6.0. Not making an adjustment for this problem almost always leads to "Access beyond end of device" errors from the Linux kernel.

Once you have made a BSD disklabel, continue the installation. After installation, you can write a boot block to your disk to make it bootable from SRM.