When using the SRM firmware, aboot
is the preferred way of
booting Linux. It supports:
ext2
, ISO9660
, and
UFS
, the DEC Unix filesystem)The latest sources for aboot
are available in
this ftp directory.
The description in this manual applies to aboot
version 0.6
or newer. Please note that many distributions ship aboot with them so
downloading aboot from this directory is probably unnessesary.
Once you downloaded and extracted the latest tar file, take a
look at the README
and INSTALL
files for
installation hints. In particular, be sure to adjust the variables in
Makefile
and in include/config.h
to match your
environment. Normally, you won't need to change anything when
building under Linux, but it is always a good idea to double check.
If you're satisfied with the configuration, simply type make
to build it (if you're not building under Linux, be advised that
aboot
requires GNU make
).
After running make
, the aboot
directory should contain the
following files:
This is the actual aboot
executable (either an
ECOFF or ELF object file).
Same as above, but it contains only the text, data and bss segments---that is, this file is not an object file.
Utility to install aboot
on a
hard disk.
Utility to install aboot
on an ext2
filesystem (usually used for floppies only).
Utility to install aboot
on a iso9660
filesystem (used by CD-ROM distributors).
Utility to configure an installed aboot
.
The bootloader can be installed on a floppy using the
e2writeboot
command (note: this can't be done on a Jensen since
its firmware does not support booting from floppy). This command
requires that the disk is not overly fragmented as it needs to find
enough contiguous file blocks to store the entire aboot
image
(currently about 90KB). If e2writeboot
fails because of this,
reformat the floppy and try again (e.g., with fdformat(1)
). For
example, the following steps install aboot
on floppy disk
assuming the floppy is in drive /dev/fd0
:
# fdformat /dev/fd0
# mke2fs /dev/fd0
# e2writeboot /dev/fd0 bootlx
Since the e2writeboot
command may fail on highly fragmented
disks and since reformatting a harddisk is not without pain, it is
generally safer to install aboot
on a harddisk using the
swriteboot
command. swriteboot
requires that the first few
sectors are reserved for booting purposes. We suggest that the disk
be partitioned such that the first partition starts at an offset of
2048 sectors. This leaves 1MB of space for storing aboot
. On
a properly partitioned disk, it is then possible to install aboot
as follows (assuming the disk is /dev/sda
):
# swriteboot /dev/sda bootlx
On systems where partition c
in the entire disk it will be
necessary to 'force' the write of aboot. In this case use the -f
flag followed by the partition number (in the case of partition c
this is 3):
# swriteboot /dev/sda bootlx -f3
On a Jensen, you will want to leave some more space, since you need to
write a kernel to this place, too---2MB should be sufficient when
using compressed kernels. Use swriteboot
as described in Section
booting
to write bootlx
together with the Linux
kernel.
To make a CD-ROM bootable by SRM, simply build aboot
as
described above. Then, make sure that the bootlx
file is present
on the iso9660 filesystem (e.g., copy bootlx
to the directory
that is the filesystem master, then run mkisofs
on that
directory). After that, all that remains to be done is to mark the
filesystem as SRM bootable. This is achieved with a command of the
form:
# isomarkboot filesystem bootlx
The command above assumes that filesystem
is a file containing
the iso9660 filesystem and that bootlx
has been copied into the
root directory of that filesystem. That's it!
A bootable Linux kernel can be built with the following steps.
During the make config
, be sure to answer "yes" to the question
whether you want to boot the kernel via SRM (for certain platforms
this is automatically selected). Note that if you build a generic
kernel (by selecting "Generic" as the alpha system type), the kernel
is able to guess whether it is running under SRM or not.
# cd /usr/src/linux
# make config
# make dep
# make boot
# make modules (if applicable)
# make modules_install (if applicable)
The last command will build the file
arch/alpha/boot/vmlinux.gz
which can then be copied to the
disk from which you want to boot from. In our floppy disk example
above, this would entail:
# mount /dev/fd0 /mnt
# cp arch/alpha/boot/vmlinux.gz /mnt
# umount /mnt
With the SRM firmware and aboot
installed, Linux is generally
booted with a command of the form:
boot
devicename -fi
filename
-fl
flags
The filename and flags arguments are optional. If
they are not specified, SRM uses the default values stored in
environment variables BOOTDEF_DEV
,
BOOT_OSFILE
and BOOT_OSFLAGS
. The
syntax and meaning of these two arguments is described in more detail
below. To list the current values of these variables type show
boot*
at the SRM command prompt. This will also show a
boot_dev variable (among others), this variable is read only
and needs to be changed via the bootdef_dev variable.
This corresponds to the device from which SRM will attempt to boot. Examples include:
- First floppy drive, /dev/fd0
under Linux
- Primary IDE cdrom or hard disk as Master, /dev/hda
under Linux
- Primary IDE cdrom or hard disk as Slave, /dev/hdb
under Linux
- SCSI disk on first bus, Device 0, /dev/sda
under Linux
- First Ethernet Device, /dev/eth0
under Linux
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
how-srm-boots
, 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.
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).
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:
Copy root file system from a (floppy) disk to the RAM disk before starting the system. The RAM disk will be used in lieu of the root device. This is useful to bootstrap Linux on a system with only one floppy drive.
Sets floppy configuration to str.
Select device dev as the root-file
system. The device can be specified as a major/minor hex number (e.g.,
0x802 for /dev/sda2) or one of a few canonical names (e.g.,
/dev/fd0
, /dev/sda2
).
Boot system in single user mode.
Enable kernel-gdb (works only if CONFIG_KGDB
is
enabled; a second Alpha system needs to be connected over the serial
port in order to make this work)
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
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
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.
When installed on a harddisk, aboot
needs to know what
partition to search for the /etc/aboot.conf
file. A newly
compiled aboot
will search the second partition (e.g.,
/dev/sda2
). Since it would be inconvenient to have to
recompile aboot
just to change the partition number,
abootconf
allows to directly modify an installed aboot
.
Specifically, if you want to change aboot
to use the third
partition on disk /dev/sda
, you'd use the command:
# abootconf /dev/sda 3
You can verify the current setting by simply omitting the partition
number. That is: abootconf /dev/sda
will print the currently
selected partition number. Note that aboot
does have to be
installed already for this command to succeed. As of version 0.6,
swriteboot
will preserve the existing configuration when
installing a new aboot
on a hard disk.
Since aboot
version 0.5, it is also possible to select the
aboot.conf
partition via the boot command line. This can be
done with a command line of the form a:
b
where a
is the partition that holds /etc/aboot.conf
and b is a
single-letter option as described above (0
-9
, i
, or
h
). For example, if you type boot -fl "3:h" dka100
the
system boots from SCSI ID 1, loads /etc/aboot.conf
from the
third partition, prints its contents on the screen and waits for you
to enter the boot options.
Three steps are necessary before Linux can be booted via a network. First you need an Ethernet adapter that is supported by SRM. Most version of SRM support the DE500 series of cards, with newer versions (5.6 and later) also supporting the Intel EtherExpress/Pro series of cards. Second, you need to set the SRM environment variables to enable booting via the bootp protocol and third you need to setup another machine as the your boot server. Enabling bootp in SRM is usually done by setting the ewa0_protocol (DE500 cards) or eia0_protocol (Intel cards) variable to bootp.
>>> set ewa0_protocol bootp
Setting up the boot server is obviously dependent on
what operating system that machine is running, but typically it
involves starting the program bootpd
in the background after
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
myhost.cs.arizona.edu
, then an entry of the following form would
be needed:
myhost.cs.arizona.edu:\
:hd=/remote/: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
/remote
. For more information on configuring bootpd
,
please refer to its man page.
Next, build aboot
with with the command make netboot
. 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.
Finally, copy vmlinux.bootp
to the bootserver's directory. In the
example above, you'd copy it into /remote/vmlinux.bootp
.
Next, power up the client machine and boot it, specifying the Ethernet
adapter as the boot device. Typically, SRM calls the first Ethernet
adapter ewa0
, so to boot from that device, you'd use the command:
>>> boot ewa0
The -fi
and -fl
options can be used as usual. In
particular, you can ask aboot
to prompt for Linux kernel
arguments by specifying the option -fl i
.
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.
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
There are some important catches that you must be aware of when partitioning using a BSD disklabel:
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.