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.
</Para>
<Para>
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 <ulink url="ftp://ftp.freesoftware.com/.1/linux/redhat/old-releases/redhat-5.2/alpha/RedHat/RPMS/">mirror</ulink>.
The bootp package requires the tftp-server just as before and the location to where the files are grabbed from is the same.
</Para>
<Para>
Once installed you must configure your inetd service to talk to the bootpd daemon. Uncomment the following line in your /etc/inetd.conf .
</Para>
<Screen>
#bootps dgram udp wait root /usr/sbin/tcpd bootpd
</Screen>
<Para>
Then restart the inetd.
</Para>
<Screen>
# service inet restart
</Screen>
<Para>
Configuring the <Literal remap="tt">/etc/bootptab</Literal> file. The <Literal remap="tt">bootptab</Literal> file
has one entry describing each client that is allowed to boot from
the server. For example, if you want to boot the machine
<Literal remap="tt">voodoo.alphalinux.org</Literal>, then an entry of the following form would
be needed:
<Screen>
voodoo.alphalinux.org:\
:hd=/tftpboot/:bf=vmlinux.bootp:\
:ht=ethernet:ha=08012B1C51F8:hn:vm=rfc1048:\
:ip=192.12.69.254:bs=auto:
</Screen>
</Para>
<Para>
This entry assumes that the machine's Ethernet address is
<Literal remap="tt">08012B1C51F8</Literal> and that its IP address is 192.12.69.254. The
Ethernet address can be found with the <Literal remap="tt">show device</Literal> command of the
SRM console or, if Linux is running, with the <Literal remap="tt">ifconfig</Literal> command.
The entry also defines that if the client does not specify otherwise,
the file that will be booted is <Literal remap="tt">vmlinux.bootp</Literal> in directory
<Literal remap="tt">/tftpboot</Literal>. For more information on configuring <Literal remap="tt">bootpd</Literal>,
please refer to its man page.
</Para>
</Sect3>
</Sect2>
<Sect2 id="Network-Booting">
<Title>Booting Over the Network</Title>
<Para>
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.
<Screen>
>>> set ewa0_protocol bootp
</Screen>
</Para>
<Para>
Also check to see that your ethernet device has a link light to whatever hub or switch it is connected to. If you
do not see a link light try forcing the negotiation of the ethernet device. For example:
</Para>
<Screen>
>>> set ewa0_mode FastFD
</Screen>
<Para> Would set the DE500 ethernet card to fast full duplex operation. To see a list of the available modes</Para>
<Screen>
>>> set ewa0_mode
</Screen>
<Para>
Netboot using the aboot sources is currently broken though for the curious the steps needed are further below. Instead use the directions for netbooting using the kernel sources.
</Para>
<Sect3>
<Title>Netboot using the kernel sources</Title>
<Para>
<OrderedList>
<Listitem>
<Para>
Make sure the kernel you want to boot has already been built
</Para>
</Listitem>
<Listitem>
<Para>
Execute the following while in the linux source dir:
<ItemizedList>
<Listitem>
<Para>
<Literal>make bootimage</Literal>
</Para>
</Listitem>
<Listitem>
<Para>
<Literal>make bootpfile</Literal>
</Para>
</Listitem>
</Itemizedlist>
</Para>
<Para>
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.
</Para>
</Listitem>
<Listitem>
<Para>
Copy bootpfile to the bootp server's directory. With a default setup the tftp server would look in
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.
</Para>
</Listitem>
<Listitem>
<Para>
Copy vmlinux.bootp to the bootp server's directory. In the example above, you'd copy it into /tftpboot/vmlinux.bootp.
</Para>
</Listitem>
</Orderedlist>
</Para>
<Para>
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:
<screen>
>>> boot ewa0
</screen>
</Para>
<Para>
The -fi and -fl options can be used as usual. For example,
</Para>
<Para>
<screen>
>>> boot ewa0 -fi bootpfile -fl "root=/dev/hda2"
</screen>
</Para>
<Para>
In particular, you can ask aboot to prompt for Linux kernel arguments by specifying the option
-fl i .
</Para>
</Sect3>
<Sect3>
<Title>Updating the SRM console through BOOTP</Title>
<Para>
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.
</Para>
<Para>
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
<ulink url="ftp://gatekeeper.dec.com/pub/DEC/Alpha/firmware/v5.8/">ftp://gatekeeper.dec.com/pub/DEC/Alpha/firmware/v5.8/</ulink>. You can also find these files on the Alpha Systems Firmware Update CD-ROM. <ulink url="http://www.api-networks.com">API NetWorks</ulink> does not offer net bootable SRM images at this time though that may change in the near future.
</Para>
<Para>
For example say you had a DS20 and wanted to update it's firmware over the network using BOOTP. You would have to,
<OrderedList>
<Listitem><Para>Get the correct firmware image for the DS20 that supported BOOTP execution which in this case the filename is
<Literal remap="tt">ds20_v5_8.exe </Literal> from <ulink url="ftp://gatekeeper.dec.com/pub/DEC/Alpha/firmware/v5.8/">ftp://gatekeeper.dec.com/pub/DEC/Alpha/firmware/v5.8/</ulink>.</Para>
</Listitem>
<Listitem>
<Para>Copy the file to the /tftpboot folder located on the BOOTP server.</Para>
</Listitem>
</OrderedList>
</Para>
<Para>
To execute the update from SRM you would do the following:
</Para>
<Screen>>>> b ewa0 -fi ds20_v5_8.exe</Screen>
<Para>
SRM would then proceed to upgrade the firmware in the same fashion as if you had done the firmware update from a CD.
</Para>
</Sect3>
</Sect2>
<Sect2>
<Title>Partitioning Disks</Title>
<Sect3>
<Title>What is a disklabel?</Title>
<Para>
A disk label is a partition table. Unfortunately, there are several
formats the partition table can take, depending on the operating
system.
</Para>
<Para>
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.
</Para>
<Para>
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.
</Para>
<Para>
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.
</Para>
</Sect3>
<Sect3>
<Title>Partitioning the Easy Way: a DOS Disklabel</Title>
<Para>
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
<Emphasis>only</Emphasis> 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
</Para>
</Sect3>
<Sect3>
<Title>Partitioning with a BSD Disklabel</Title>
<Para>
<OrderedList>
<ListItem>
<Para>
Start fdisk on the disk you're configuring
</Para>
</ListItem>
<ListItem>
<Para>
Choose to make a BSD disklabel - option 'b' (newer versions of
fdisk will detect existing BSD disklabels and automatically enter
disklabel mode)
</Para>
</ListItem>
<ListItem>
<Para>
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
</Para>
</ListItem>
<ListItem>
<Para>
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
</Para>
</ListItem>
<ListItem>
<Para>
Setting partition type is slightly different, because the
numbering scheme is different (1 is swap, 8 is ext2).
</Para>
</ListItem>
<ListItem>
<Para>
When you are finished, write ('w') and quit ('q') as normal.
</Para>
</ListItem>
</OrderedList>
</Para>
<Para>
There are some important catches that you must be aware of when
partitioning using a BSD disklabel:
<ItemizedList>
<ListItem>
<Para>
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)
</Para>
</ListItem>
<ListItem>
<Para>
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
</Para>
</ListItem>
<ListItem>
<Para>
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.
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
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.
</Para>
</Sect3>
</Sect2>
</Sect1>
<Sect1>
<Title>Sharing a Disk With DEC Unix</Title>
<Para>
Unfortunately, DEC Unix doesn't know anything about Linux, so sharing
a single disk between the two OSes is not entirely trivial. However,
it is not a difficult task if you heed the tips in this section. The
section assumes you are using <Literal remap="tt">aboot</Literal> version 0.5 or newer.
</Para>
<Sect2>
<Title>Partitioning the disk</Title>
<Para>
First and foremost: <Emphasis>never</Emphasis> use any of the Linux partitioning
programs (<Literal remap="tt">minlabel</Literal> or <Literal remap="tt">fdisk</Literal>) on a disk that is also
used by DEC Unix. The Linux <Literal remap="tt">minlabel</Literal> program uses the same
partition table format as DEC Unix <Literal remap="tt">disklabel</Literal>, but there are
some incompatibilities in the data that <Literal remap="tt">minlabel</Literal> fills in, so
DEC Unix will simply refuse to accept a partition table generated by
<Literal remap="tt">minlabel</Literal>. To setup a Linux <Literal remap="tt">ext2</Literal> partition under DEC
Unix, you'll have to change the disktab entry for your disk. For the
purpose of this discussion, let's assume that you have an rz26 disk (a
common 1GB drive) on which you want to install Linux. The disktab
entry under DEC Unix v3.2 looks like this (see file
<Literal remap="tt">/etc/disktab</Literal>):
<Screen>
rz26|RZ26|DEC RZ26 Winchester:\
:ty=winchester:dt=SCSI:ns#57:nt#14:nc#2570:\
:oa#0:pa#131072:ba#8192:fa#1024:\
:ob#131072:pb#262144:bb#8192:fb#1024:\
:oc#0:pc#2050860:bc#8192:fc#1024:\
:od#393216:pd#552548:bd#8192:fd#1024:\
:oe#945764:pe#552548:be#8192:fe#1024:\
:of#1498312:pf#552548:bf#8192:ff#1024:\
:og#393216:pg#819200:bg#8192:fg#1024:\
:oh#1212416:ph#838444:bh#8192:fh#1024:
</Screen>
</Para>
<Para>
The interesting fields here are <Literal remap="tt">o</Literal><Emphasis remap="it">?</Emphasis>, and
<Literal remap="tt">p</Literal><Emphasis remap="it">?</Emphasis>, where <Emphasis remap="it">?</Emphasis> is a letter in the range
<Literal remap="tt">a</Literal>-<Literal remap="tt">h</Literal> (first through 8-th partition). The <Literal remap="tt">o</Literal>
value gives the starting offset of the partition (in sectors) and the
<Literal remap="tt">p</Literal> value gives the size of the partition (also in sectors).
See <Literal remap="tt">disktab(4)</Literal> for more info. Note that DEC Unix likes to
define overlapping partitions. For the entry above, the partition
layout looks like this (you can verify this by adding up the various
<Literal remap="tt">o</Literal> and <Literal remap="tt">p</Literal> values):
<Screen>
a b d e f
|---|-------|-----------|-----------|-----------|
c
|-----------------------------------------------|
g h
|-----------------|-----------------|
</Screen>
</Para>
<Para>
DEC Unix insists that partition <Literal remap="tt">a</Literal> starts at offset 0 and that
partition <Literal remap="tt">c</Literal> spans the entire disk. Other than that, you can
setup the partition table any way you like.
</Para>
<Para>
Let's suppose you have DEC Unix using partition <Literal remap="tt">g</Literal> and want to
install Linux on partition <Literal remap="tt">h</Literal> with partition <Literal remap="tt">b</Literal> being a
(largish) swap partition. To get this layout without destroying the
existing DEC Unix partition, you need to set the partition types
explicitly. You can do this by adding a <Literal remap="tt">t</Literal> field for each
partition. In our case, we add the following line to the above
disktab entry.
<Screen>
:ta=unused:tb=swap:tg=4.2BSD:th=resrvd8:
</Screen>
</Para>
<Para>
Now why do we mark partition <Literal remap="tt">h</Literal> as "reservd8" instead of "ext2"?
Well, DEC Unix doesn't know about Linux. It so happens that partition
type "ext2" corresponds to a numeric value of 8, and DEC Unix uses the
string "reservd8" for that value. Thus, in DEC Unix speak, "reservd8"
means "ext2". OK, this was the hard part. Now we just need to
install the updated disktab entry on the disk. Let's assume the disk
has SCSI id 5. In this case, we'd do:
<Screen>
# disklabel -rw /dev/rrz5c rz26
</Screen>
</Para>
<Para>
You can verify that everything is all right by reading back the
disklabel with <Literal remap="tt">disklabel -r /dev/rrz5c</Literal>. At this point, you
may want to reboot DEC Unix and make sure the existing DEC Unix
partition is still alive and well. If that is the case, you can shut
down the machine and start with the Linux installation. Be sure to
skip the disk partitioning step during the install. Since we already
installed a good partition table, you should be able to proceed and
select the 8th partition as the Linux root partition and the 2nd
partition as the swap partition. If the disk is, say, the second SCSI
disk in the machine, then the device name for these partitions would
be <Literal remap="tt">/dev/sdb8</Literal> and <Literal remap="tt">/dev/sdb2</Literal>, respectively (note that
Linux uses letters to name the drives and numbers to name the
partitions, which is exactly reversed from what DEC Unix does; the