mirror of https://github.com/tLDP/LDP
2217 lines
67 KiB
Plaintext
2217 lines
67 KiB
Plaintext
<!DOCTYPE Article PUBLIC "-//Davenport//DTD DocBook V3.0//EN">
|
|
|
|
<Article>
|
|
|
|
<ArtHeader>
|
|
|
|
<Title>SRM Firmware Howto</Title>
|
|
<AUTHORGROUP>
|
|
<AUTHOR>
|
|
<FirstName>Rich</FirstName>
|
|
<Surname>Payne</Surname>
|
|
|
|
<Affiliation>
|
|
<Address><Email>rdp@alphalinux.org</Email></Address>
|
|
</Affiliation>
|
|
</AUTHOR>
|
|
<AUTHOR>
|
|
<FirstName>David</FirstName>
|
|
<Surname>Huggins-Daines</Surname>
|
|
<Affiliation>
|
|
<Address><Email>dhuggins@linuxcare.com</Email></Address>
|
|
</Affiliation>
|
|
</AUTHOR>
|
|
</AUTHORGROUP>
|
|
<PubDate>v0.8, 09 November 2000</PubDate>
|
|
|
|
<Abstract>
|
|
|
|
<Para>
|
|
This document describes how to boot Linux/Alpha using the SRM console,
|
|
which is the console firmware also used to boot Compaq Tru64 Unix
|
|
(also known as Digital Unix and OSF/1) and OpenVMS.
|
|
</Para>
|
|
|
|
</Abstract>
|
|
|
|
</ArtHeader>
|
|
|
|
<Sect1>
|
|
<Title>About this manual</Title>
|
|
|
|
<Sect2>
|
|
<Title>Who should read this manual</Title>
|
|
|
|
<Para>
|
|
You should read this manual if you are installing Linux on a new
|
|
Alpha system that can only boot from the SRM console, or if you are
|
|
installing Linux on an older Alpha system that can use the SRM console
|
|
and wish to use SRM to boot your Linux installation.
|
|
</Para>
|
|
|
|
<Para>
|
|
Because SRM is the only way to boot Linux on modern Alpha systems,
|
|
and because it provides the proper operating environment for Unix and
|
|
Unix-like operating systems (such as Linux), it is the recommended way
|
|
of booting Linux on Alpha when available.
|
|
</Para>
|
|
|
|
<Para>
|
|
Sometimes, it is preferable to use the ARC, ARCSBIOS, or AlphaBIOS
|
|
console, such as if you have a machine for which SRM is not available,
|
|
if you wish to dual-boot with Windows NT without switching consoles,
|
|
or if you have hardware that is not supported by SRM. On these
|
|
machines, you will typically use MILO to boot Linux. For more
|
|
information, refer to the MILO Howto, available from
|
|
<ULink
|
|
URL="http://www.alphalinux.org/faq/milo.html"
|
|
>http://www.alphalinux.org/faq/milo.html</ULink
|
|
>.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Conventions</Title>
|
|
|
|
<Para>
|
|
Throughout this manual, we will use the following conventions for
|
|
commands to be entered by the user:
|
|
</Para>
|
|
|
|
<Para>
|
|
SRM console commands will be shown with the characteristic SRM
|
|
'>>>' prompt, like this:
|
|
<FOOTNOTE>
|
|
|
|
<Para>
|
|
On multiprocessor machines, you
|
|
will see 'P00>>' instead, or possibly some other number depending on
|
|
which processor SRM is running.
|
|
</Para>
|
|
|
|
</FOOTNOTE>
|
|
|
|
|
|
<Screen>
|
|
>>> boot dva0 -fi linux.gz -fl "root=/dev/fd0 load_ramdisk=1"
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Unix commands will be shown with the '#' command prompt if they are
|
|
to be run as <Literal remap="tt">root</Literal>, or '$' if they are to be run by a normal user,
|
|
like this:
|
|
|
|
<Screen>
|
|
# swriteboot -f3 /dev/sda /boot/bootlx
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Aboot commands will be shown with the 'aboot>' command prompt, like
|
|
this:
|
|
|
|
<Screen>
|
|
aboot> b 6/boot/vmlinuz root=/dev/hda6
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1>
|
|
<Title>What is SRM?</Title>
|
|
|
|
<Para>
|
|
SRM console is used by Alpha systems as
|
|
Unix-style boot firmware. Tru64 Unix and OpenVMS depend on it and
|
|
Linux can boot from it. You can recognize SRM console as a blue screen
|
|
with a prompt that is presented to you on power-up.
|
|
</Para>
|
|
|
|
<Sect2>
|
|
<Title>Getting to SRM</Title>
|
|
|
|
<Para>
|
|
Most Alpha systems have both the SRM and ARC/AlphaBIOS console in
|
|
their firmware. On one of these machines, if your machine starts up
|
|
with ARC/AlphaBIOS by default, you can switch to SRM through the
|
|
"Console Selection" option in the Advanced CMOS Setup menu. To make
|
|
the change permanent, you should set the <Literal remap="tt">os_type</Literal> environment
|
|
variable in SRM to "OpenVMS" or "Unix", like this:
|
|
|
|
<Screen>
|
|
>>> set os_type Unix
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Either one will work to boot Linux. However, if you intend to
|
|
dual-boot OpenVMS on this machine, you must set <Literal remap="tt">os_type</Literal> to
|
|
"OpenVMS". Conversely, to return to ARC/AlphaBIOS, you can set
|
|
<Literal remap="tt">os_type</Literal> to "NT".
|
|
</Para>
|
|
|
|
<Para>
|
|
Some older systems may not have both SRM and ARC in firmware as
|
|
shipped. On these systems, you will have to upgrade your firmware.
|
|
See <ULink
|
|
URL="http://ftp.digital.com/pub/DEC/Alpha/firmware/"
|
|
>http://ftp.digital.com/pub/DEC/Alpha/firmware</ULink
|
|
> for the
|
|
latest firmware updates and instructions.
|
|
</Para>
|
|
|
|
<Para>
|
|
A few older systems (primarily evaluation boards such as the 164SX
|
|
and 164LX) are "half-flash" systems, whose firmware can hold SRM or
|
|
AlphaBIOS, but not both. If you have one of these machines, you will
|
|
have to reflash your firmware with the SRM console using the AlphaBIOS
|
|
firmware update utility. Again, see
|
|
<ULink
|
|
URL="http://ftp.digital.com/pub/DEC/Alpha/firmware/"
|
|
>http://ftp.digital.com/pub/DEC/Alpha/firmware</ULink
|
|
> for firmware
|
|
images and instructions. If you wish to return to AlphaBIOS on these
|
|
machines, you may rerun the firmware update utility from a floppy in
|
|
SRM using the <Literal remap="tt">fwupdate</Literal> command. You can also start AlphaBIOS
|
|
from a floppy using the <Literal remap="tt">arc</Literal> command.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Using the SRM console</Title>
|
|
|
|
<Para>
|
|
The SRM console works very much like a Unix or OpenVMS shell. It
|
|
views your NVRAM and devices as a pseudo-filesystem. You can see this
|
|
if you use the <Literal remap="tt">ls</Literal> command. Also, it contains a fairly large set
|
|
of diagnostic, setup, and debugging utilities, the details of which
|
|
are beyond the scope of this document. As in the Unix shell, you can
|
|
pipe the output of one command to the input of another, and there is a
|
|
<Literal remap="tt">more</Literal> command that works not unlike the Unix one. To get a full
|
|
listing of available commands, run:
|
|
|
|
<Screen>
|
|
>>> help | more
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
As well, SRM has environment variables, a number of which are
|
|
pre-defined and correspond to locations in NVRAM. You can view the
|
|
entire list of environment variables and their values with the
|
|
<Literal remap="tt">show</Literal> command (there are quite a few of them, so you will probably
|
|
want to pipe its output to <Literal remap="tt">more</Literal>). You can also show variables
|
|
matching a "glob" pattern - for example, <Literal remap="tt">show boot*</Literal> will show all
|
|
the variables starting in "boot".
|
|
</Para>
|
|
|
|
<Para>
|
|
Environment variables are categorized as either <Emphasis>read-only</Emphasis>,
|
|
<Emphasis>warm non-volatile</Emphasis>, or <Emphasis>cold non-volatile</Emphasis>. The full listing
|
|
of pre-defined variables is detailed in the Alpha Architecture
|
|
Reference Manual. The most useful pre-defined environment variables
|
|
for the purposes of booting Linux are <Literal remap="tt">bootdef_dev</Literal>,
|
|
<Literal remap="tt">boot_file</Literal>, <Literal remap="tt">boot_flags</Literal>, and
|
|
<Literal remap="tt">auto_action</Literal>, all of which are cold non-volatile.
|
|
</Para>
|
|
|
|
<Para>
|
|
To set environment variables, use the <Literal remap="tt">set</Literal> command, like this:
|
|
|
|
<Screen>
|
|
>>> set bootdef_def dka0
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
If you set an undefined variable, it will be created for you, however
|
|
it will not persist across reboots.
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Literal remap="tt">bootdef_dev</Literal> variable specifies the device (using
|
|
VMS naming conventions - see <XRef LinkEnd="device-naming"> for an
|
|
explanation of these) which will be booted from if no device is
|
|
specified on the <Literal remap="tt">boot</Literal> command line, or in an automatic boot.
|
|
The <Literal remap="tt">boot_file</Literal> variable contains the filename to be
|
|
loaded by the secondary bootloader, while <Literal remap="tt">boot_flags</Literal>
|
|
contains any extra flags. <Literal remap="tt">auto_action</Literal> specifies the
|
|
action which the console should take on power-up. By default, it is
|
|
set to <Literal remap="tt">HALT</Literal>, meaning that the machine will start up in the
|
|
SRM console. Once you have configured your bootloader and the
|
|
boot-related variables, you can set it to <Literal remap="tt">BOOT</Literal> in order to
|
|
boot automatically on power-up.
|
|
</Para>
|
|
|
|
<Para>
|
|
Finally, two helpful console keystrokes you should know are
|
|
Control-C, which, as in the shell, halts a command in progress (such
|
|
as an automatic boot), and Control-P, which if issued from the aboot
|
|
prompt (or other secondary bootloader) will halt the bootloader and
|
|
return you to the SRM console.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2 id="how-srm-boots">
|
|
<Title>How Does SRM Boot an OS?</Title>
|
|
|
|
<Para>
|
|
All versions of SRM can boot from SCSI disks and the versions for
|
|
recent platforms, such as the Noname or AlphaStations can boot from
|
|
floppy disks as well. Network booting via <Literal remap="tt">bootp</Literal> is supported.
|
|
Note that older SRM versions (notably the one for the Jensen)
|
|
cannot boot from floppy disks. Booting from IDE devices
|
|
is supported on newer platforms ( 164SX, 164LX, 164UX, DS20, DS10, DP264, UP2000(+), UP1000, UP1100 etc..).
|
|
</Para>
|
|
|
|
<Para>
|
|
Booting Linux with SRM is a two step process: first, SRM loads and
|
|
transfers control to the secondary bootstrap loader. Then the
|
|
secondary bootstrap loader sets up the environment for Linux, reads
|
|
the kernel image from a disk filesystem and finally transfers control to Linux.
|
|
</Para>
|
|
|
|
<Para>
|
|
Currently, there are two secondary bootstrap loaders for Linux:
|
|
the <Emphasis>raw</Emphasis> loader that comes with the Linux kernel and <Literal remap="tt">aboot</Literal>
|
|
which is distributed separately. These two loaders are described in
|
|
more detail below.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Loading The Secondary Bootstrap Loader</Title>
|
|
|
|
<Para>
|
|
SRM knows nothing about filesystems or disk-partitions. It simply
|
|
expects that the secondary bootstrap loader occupies a consecutive
|
|
range of physical disk sector, starting from a given offset. The
|
|
information on the size of the secondary bootstrap loader and the
|
|
offset of its first disk sector is stored in the first 512 byte
|
|
sector. Specifically, the long integer at offset 480 stores the
|
|
<Emphasis>size</Emphasis> of the secondary bootstrap loader (in 512-byte blocks) and
|
|
the long at offset 488 gives the <Emphasis>sector number</Emphasis> at which the
|
|
secondary bootstrap loader starts. The first sector also stores a
|
|
flag-word at offset 496 which is always 0 and a checksum at offset
|
|
504. The checksum is simply the sum of the first 63 long integers in
|
|
the first sector.
|
|
</Para>
|
|
|
|
<Para>
|
|
If the checksum in the first sector is correct, SRM goes ahead and
|
|
reads the <Emphasis>size</Emphasis> sectors starting from the sector given in the
|
|
<Emphasis>sector number</Emphasis> field and places them in <Emphasis>virtual</Emphasis> memory at
|
|
address <Literal remap="tt">0x20000000</Literal>. If the reading completes successfully,
|
|
SRM performs a jump to address <Literal remap="tt">0x20000000</Literal>.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1>
|
|
<Title>SRM Device Naming</Title>
|
|
<Sect2>
|
|
<Title>The First Two Letter</Title>
|
|
<Para>The following is based on the example device dkb1.2.3.4.5 taken from a Digital Server 3300 (Whitebox version of
|
|
an AS800).
|
|
</Para>
|
|
<Para>
|
|
Two letter port or class driver designator:
|
|
<ItemizedList>
|
|
<ListItem><Para> DR: RAID set device </Para></ListItem>
|
|
<ListItem><Para> DV: Floppy Drive </Para></ListItem>
|
|
<ListItem><Para> EW: Ethernet port (TULIP, DEC 21040) </Para></ListItem>
|
|
<ListItem><Para> EI: Ethernet port (Intel 82557 or 82559) </Para></ListItem>
|
|
<ListItem><Para> PK: SCSI port (controller) </Para></ListItem>
|
|
<ListItem><Para> DK: SCSI disk </Para></ListItem>
|
|
<ListItem><Para> MK: SCSI tape </Para></ListItem>
|
|
<ListItem><Para> PU: DSSI port </Para></ListItem>
|
|
<ListItem><Para> DU: DSSI disk </Para></ListItem>
|
|
<ListItem><Para> MU: DSSI tape </Para></ListItem>
|
|
<ListItem><Para> JK: SCSI monitor (or robot) </Para></ListItem>
|
|
<ListItem><Para> DQ: (E)IDE Device (disk or CD-ROM)</Para></ListItem>
|
|
</ItemizedList>
|
|
</Para>
|
|
</Sect2>
|
|
<Sect2>
|
|
<Title>The Rest Of The Device Name</Title>
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem><Para>
|
|
b-> adapter ID (one letter adapter designator)</Para></ListItem>
|
|
|
|
<ListItem><Para>
|
|
1->Device number (SCSI unit numbers are forced to 100x Node ID)</Para></ListItem>
|
|
|
|
<ListItem><Para>
|
|
2->Bus Node ID</Para></ListItem>
|
|
|
|
<ListItem><Para>
|
|
3->Channel Number</Para></ListItem>
|
|
|
|
<ListItem><Para>
|
|
4->Channel Number (used for multi-channel devices)</Para></ListItem>
|
|
|
|
<ListItem><Para>
|
|
5->Logical Slot number
|
|
|
|
<ItemizedList>
|
|
<ListItem><Para>EISA: they correspond to the physical slot numbers (1-3)</Para></ListItem>
|
|
<ListItem><Para>PCI:</Para>
|
|
<ItemizedList>
|
|
<ListItem><Para>slot 5= SCSI controller on system backplane (DS3300)</Para></ListItem>
|
|
<ListItem><Para>slot 6= On board VGA (DS3300)</Para></ListItem>
|
|
<ListItem><Para>slot 7= PCI to EISA bridge chip (DS3300)</Para></ListItem>
|
|
<ListItem><Para>slots 11 - 14 = Correspond to Physical PCI option slots:
|
|
PCI11, PCI12, PCI13 and PCI14 (64bit) (DS3300)</Para></ListItem>
|
|
</ItemizedList>
|
|
</ListItem>
|
|
</ItemizedList>
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem><Para>
|
|
6->Hose number: 0 PCI_0 (32bit PCI); 1 EISA (DS3300)</Para></ListItem>
|
|
|
|
</ItemizedList>
|
|
</Para>
|
|
</Sect2>
|
|
</Sect1>
|
|
|
|
|
|
<Sect1>
|
|
<Title>The Raw Loader</Title>
|
|
|
|
<Para>
|
|
The sources for this loader can be found in directory
|
|
<Literal remap="tt">arch/alpha/boot</Literal> of the Linux kernel source
|
|
distribution. It loads the Linux kernel by reading
|
|
<Literal remap="tt">START_SIZE</Literal> bytes starting at disk offset
|
|
<Literal remap="tt">BOOT_SIZE+512</Literal> (also in bytes). The constants
|
|
<Literal remap="tt">START_SIZE</Literal> and <Literal remap="tt">BOOT_SIZE</Literal> are defined in
|
|
<Literal remap="tt">linux/include/asm-alpha/system.h</Literal>. <Literal remap="tt">START_SIZE</Literal>
|
|
must be at least as big as the kernel image (i.e., the size of the
|
|
<Literal remap="tt">.text</Literal>, <Literal remap="tt">.data</Literal>, and <Literal remap="tt">.bss</Literal> segments). Similarly,
|
|
<Literal remap="tt">BOOT_SIZE</Literal> must be at least as big as the image of the raw
|
|
bootstrap loader. Both constants should be an integer multiple of the
|
|
sector size, which is 512 bytes. The default values are currently 2MB
|
|
for <Literal remap="tt">START_SIZE</Literal> and 16KB for <Literal remap="tt">BOOT_SIZE</Literal>. Note
|
|
that if you want to boot from a 1.44MB floppy disk, you have to reduce
|
|
<Literal remap="tt">START_SIZE</Literal> to 1400KB and make sure that the kernel you
|
|
want to boot is no bigger than that.
|
|
</Para>
|
|
|
|
<Para>
|
|
To build a raw loader, simply type <Literal remap="tt">make rawboot</Literal> in the top
|
|
directory of your linux source tree (typically
|
|
<Literal remap="tt">/usr/src/linux</Literal>). This should produce the following files in
|
|
<Literal remap="tt">arch/alpha/boot</Literal>:
|
|
</Para>
|
|
|
|
<Para>
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term><Literal remap="tt">tools/lxboot</Literal>:</Term>
|
|
<ListItem>
|
|
<Para>
|
|
The first
|
|
sector on the disk. It contains the offset and size of
|
|
the next file in the format described above.
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term><Literal remap="tt">tools/bootlx</Literal>:</Term>
|
|
<ListItem>
|
|
<Para>
|
|
The raw boot loader that
|
|
will load the file below.
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term><Literal remap="tt">vmlinux.nh</Literal>:</Term>
|
|
<ListItem>
|
|
<Para>
|
|
The raw kernel image consisting of
|
|
the <Literal remap="tt">.text</Literal>, <Literal remap="tt">.data</Literal>, and <Literal remap="tt">.bss</Literal> segments of the
|
|
object file in <Literal remap="tt">/usr/src/linux/vmlinux</Literal>. The
|
|
extension <Literal remap="tt">.nh</Literal> indicates that this file has no object-file
|
|
header.
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
<Para>
|
|
The concatenation of these three files should be written to the
|
|
disk from which you want to boot. For example, to boot from a floppy,
|
|
insert an empty floppy disk in, say, <Literal remap="tt">/dev/fd0</Literal> and then type:
|
|
|
|
<Screen>
|
|
# cat tools/lxboot tools/bootlx vmlinux >/dev/fd0
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
You can then shutdown the system and boot from the floppy by
|
|
issuing the command <Literal remap="tt">boot dva0</Literal>.
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1 id="aboot">
|
|
<Title>The aboot Loader</Title>
|
|
|
|
<Para>
|
|
When using the SRM firmware, <Literal remap="tt">aboot</Literal> is the preferred way of
|
|
booting Linux. It supports:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
direct booting from various filesystems (<Literal remap="tt">ext2</Literal>, <Literal remap="tt">ISO9660</Literal>, and
|
|
<Literal remap="tt">UFS</Literal>, the DEC Unix filesystem)
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
listing directories and following symbolic links on ext2 (version 0.6 and later)
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
booting of executable object files (both ELF and ECOFF)
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
booting compressed kernels
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
network booting (using bootp)
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
partition tables in DEC Unix format (which is
|
|
compatible with BSD Unix partition tables)
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
interactive booting and default configurations for
|
|
SRM consoles that cannot pass long option strings
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
|
|
<Para>
|
|
load initrd images to load modules at boot time (0.7 and later)
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
<Sect2>
|
|
<Title>Getting and Building aboot</Title>
|
|
|
|
<Para>
|
|
The latest sources for <Literal remap="tt">aboot</Literal> are available from <ULink
|
|
URL="ftp://ftp.alphalinux.org/pub/Linux-Alpha/aboot"
|
|
>alphalinux.org</ULink> and <ULink URL="http://www.alphalinux.org/mirrors">alphalinux.org mirrors</ULink>. They can
|
|
also be obtained via CVS from www.alphalinux.org, to get the latest version from CVS use these commands:
|
|
<Screen>
|
|
bash$ export CVSROOT=':pserver:anonymous@www.alphalinux.org:/home/axplinux/cvs/development'
|
|
bash$ cvs login
|
|
bash# cvs -z3 co aboot
|
|
</Screen>
|
|
(Note there is no password for the CVS login, just press enter)
|
|
</Para>
|
|
|
|
<Para>
|
|
The description in this manual applies to <Literal remap="tt">aboot</Literal> version 0.6
|
|
or newer. Please note that many distributions ship aboot with them so
|
|
downloading aboot from this directory is probably not neccesary.
|
|
</Para>
|
|
|
|
<Para>
|
|
Once you downloaded and extracted the latest tar file, take a
|
|
look at the <Literal remap="tt">README</Literal> and <Literal remap="tt">INSTALL</Literal> files for
|
|
installation hints. In particular, be sure to adjust the variables in
|
|
<Literal remap="tt">Makefile</Literal> and in <Literal remap="tt">include/config.h</Literal> 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 <Literal remap="tt">make</Literal>
|
|
to build it (if you're not building under Linux, be advised that
|
|
<Literal remap="tt">aboot</Literal> requires GNU <Literal remap="tt">make</Literal>).
|
|
</Para>
|
|
|
|
<Para>
|
|
After running <Literal remap="tt">make</Literal>, the <Literal remap="tt">aboot</Literal> directory should contain the
|
|
following files:
|
|
</Para>
|
|
|
|
<Para>
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>aboot</Term>
|
|
<ListItem>
|
|
<Para>
|
|
This is the actual <Literal remap="tt">aboot</Literal> executable (either an
|
|
ECOFF or ELF object file).
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>bootlx</Term>
|
|
<ListItem>
|
|
<Para>
|
|
Same as above, but it contains only the text, data
|
|
and bss segments---that is, this file is not an object file.
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>sdisklabel/writeboot</Term>
|
|
<ListItem>
|
|
<Para>
|
|
Utility to install <Literal remap="tt">aboot</Literal> on a
|
|
hard disk.
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>tools/e2writeboot</Term>
|
|
<ListItem>
|
|
<Para>
|
|
Utility to install <Literal remap="tt">aboot</Literal> on an ext2
|
|
filesystem (usually used for floppies only).
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>tools/isomarkboot</Term>
|
|
<ListItem>
|
|
<Para>
|
|
Utility to install <Literal remap="tt">aboot</Literal> on a iso9660
|
|
filesystem (used by CD-ROM distributors).
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>tools/abootconf</Term>
|
|
<ListItem>
|
|
<Para>
|
|
Utility to configure an installed <Literal remap="tt">aboot</Literal>.
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Floppy Installation</Title>
|
|
|
|
<Para>
|
|
The bootloader can be installed on a floppy using the
|
|
<Literal remap="tt">e2writeboot</Literal> command (note: this can't be done on a Jensen since
|
|
its firmware does <Emphasis>not</Emphasis> 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 <Literal remap="tt">aboot</Literal> image
|
|
(currently about 90KB). If <Literal remap="tt">e2writeboot</Literal> fails because of this,
|
|
reformat the floppy and try again (e.g., with <Literal remap="tt">fdformat(1)</Literal>). For
|
|
example, the following steps install <Literal remap="tt">aboot</Literal> on floppy disk
|
|
assuming the floppy is in drive <Literal remap="tt">/dev/fd0</Literal>:
|
|
|
|
<Screen>
|
|
# fdformat /dev/fd0
|
|
# mke2fs /dev/fd0
|
|
# e2writeboot /dev/fd0 bootlx
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Harddisk Installation</Title>
|
|
|
|
<Para>
|
|
Since the <Literal remap="tt">e2writeboot</Literal> command may fail on highly fragmented
|
|
disks and since reformatting a harddisk is not without pain, it is
|
|
generally safer to install <Literal remap="tt">aboot</Literal> on a harddisk using the
|
|
<Literal remap="tt">swriteboot</Literal> command. <Literal remap="tt">swriteboot</Literal> 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 <Literal remap="tt">aboot</Literal>. On
|
|
a properly partitioned disk, it is then possible to install <Literal remap="tt">aboot</Literal>
|
|
as follows (assuming the disk is <Literal remap="tt">/dev/sda</Literal>):
|
|
|
|
<Screen>
|
|
# swriteboot /dev/sda bootlx
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
On systems where partition <Literal remap="tt">c</Literal> in the entire disk it will be
|
|
necessary to 'force' the write of aboot. In this case use the <Literal remap="tt">-f</Literal>
|
|
flag followed by the partition number (in the case of partition <Literal remap="tt">c</Literal>
|
|
this is 3):
|
|
|
|
<Screen>
|
|
# swriteboot /dev/sda bootlx -f3
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
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 <Literal remap="tt">swriteboot</Literal> as described in Section
|
|
<XRef LinkEnd="booting"> to write <Literal remap="tt">bootlx</Literal> together with the Linux
|
|
kernel.
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>CD-ROM Installation</Title>
|
|
|
|
<Para>
|
|
To make a CD-ROM bootable by SRM, simply build <Literal remap="tt">aboot</Literal> as
|
|
described above. Then, make sure that the <Literal remap="tt">bootlx</Literal> file is present
|
|
on the iso9660 filesystem (e.g., copy <Literal remap="tt">bootlx</Literal> to the directory
|
|
that is the filesystem master, then run <Literal remap="tt">mkisofs</Literal> 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:
|
|
|
|
<Screen>
|
|
# isomarkboot filesystem bootlx
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
The command above assumes that <Literal remap="tt">filesystem</Literal> is a file containing
|
|
the iso9660 filesystem and that <Literal remap="tt">bootlx</Literal> has been copied into the
|
|
root directory of that filesystem. That's it!
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2 id="Building-Linux">
|
|
<Title>Building the Linux Kernel</Title>
|
|
|
|
<Para>
|
|
A bootable Linux kernel can be built with the following steps.
|
|
During the <Literal remap="tt">make config</Literal>, 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.
|
|
|
|
<Screen>
|
|
# cd /usr/src/linux
|
|
# make config
|
|
# make dep
|
|
# make boot
|
|
# make modules (if applicable)
|
|
# make modules_install (if applicable)
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
The last command will build the file
|
|
<Literal remap="tt">arch/alpha/boot/vmlinux.gz</Literal> which can then be copied to the
|
|
disk from which you want to boot from. In our floppy disk example
|
|
above, this would entail:
|
|
|
|
<Screen>
|
|
# mount /dev/fd0 /mnt
|
|
# cp arch/alpha/boot/vmlinux.gz /mnt
|
|
# umount /mnt
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2 id="booting">
|
|
<Title>Booting Linux</Title>
|
|
|
|
<Para>
|
|
With the SRM firmware and <Literal remap="tt">aboot</Literal> installed, Linux is generally
|
|
booted with a command of the form:
|
|
|
|
<Screen>
|
|
<Literal remap="tt">boot</Literal> <Emphasis remap="it">devicename</Emphasis> <Literal remap="tt">-fi</Literal> <Emphasis remap="it">filename</Emphasis>
|
|
<Literal remap="tt">-fl</Literal> <Emphasis remap="it">flags</Emphasis>
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Emphasis remap="it">filename</Emphasis> and <Emphasis remap="it">flags</Emphasis> arguments are optional. If
|
|
they are not specified, SRM uses the default values stored in
|
|
environment variables <Literal remap="tt">BOOTDEF_DEV</Literal> ,
|
|
<Literal remap="tt">BOOT_OSFILE</Literal> and <Literal remap="tt">BOOT_OSFLAGS</Literal>. The
|
|
syntax and meaning of these two arguments is described in more detail
|
|
below. To list the current values of these variables type <Literal remap="tt">show
|
|
boot*</Literal> 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.
|
|
</Para>
|
|
|
|
<Sect3 id="device-naming">
|
|
<Title>Device Naming</Title>
|
|
|
|
<Para>
|
|
This corresponds to the device from which SRM will attempt to boot. Examples include:
|
|
</Para>
|
|
|
|
<Para>
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>dva0</Term>
|
|
<ListItem>
|
|
<Para>
|
|
- First floppy drive, <Literal remap="tt">/dev/fd0</Literal> under Linux
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>dqa0</Term>
|
|
<ListItem>
|
|
<Para>
|
|
- Primary IDE cdrom or hard disk as Master, <Literal remap="tt">/dev/hda</Literal> under Linux
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>dqa1</Term>
|
|
<ListItem>
|
|
<Para>
|
|
- Primary IDE cdrom or hard disk as Slave, <Literal remap="tt">/dev/hdb</Literal> under Linux
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>dka0</Term>
|
|
<ListItem>
|
|
<Para>
|
|
- SCSI disk on first bus, Device 0, <Literal remap="tt">/dev/sda</Literal> under Linux
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>ewa0</Term>
|
|
<ListItem>
|
|
<Para>
|
|
- First Ethernet Device, <Literal remap="tt">/dev/eth0</Literal> under Linux
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
<Para>
|
|
For example to boot from the disk at SCSI id 6, you would enter:
|
|
|
|
<Screen>
|
|
>>> boot dka600
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
To list the devices currently installed in the system type <Literal remap="tt">show
|
|
dev</Literal> at the SRM command line. In contrast to Linux device naming, the
|
|
partition number on a disk device is <Emphasis>not</Emphasis> given as part of the
|
|
device name (you may see extra numbers after the device names when
|
|
running <Literal remap="tt">show dev</Literal> - these correspond to things like PCI bus and
|
|
device numbers and are not useful to the user). Remember, as
|
|
mentioned in <XRef LinkEnd="how-srm-boots">, that SRM knows <Emphasis>nothing</Emphasis>
|
|
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.
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3>
|
|
<Title>Boot Filename</Title>
|
|
|
|
<Para>
|
|
The filename argument takes the form:
|
|
<QUOTE
|
|
>[<Emphasis>n</Emphasis>/]<Emphasis>filename</Emphasis></QUOTE
|
|
>
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis>n</Emphasis> is a single digit in the range 1..8 that gives the partition
|
|
number from which to boot from. <Emphasis>filename</Emphasis> 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:
|
|
|
|
<Screen>
|
|
>>> boot dka600 -file 2/vmlinux.gz
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
Or to boot from floppy drive 0, you'd enter:
|
|
|
|
<Screen>
|
|
>>> boot dva0 -file vmlinux.gz
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
If a disk has no partition table, <Literal remap="tt">aboot</Literal> pretends the disk
|
|
contains one <Literal remap="tt">ext2</Literal> partition starting at the first diskblock.
|
|
This allows booting from floppy disks.
|
|
</Para>
|
|
|
|
<Para>
|
|
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, <Literal remap="tt">aboot</Literal> assumes that the Linux
|
|
kernel is stored right behind the <Literal remap="tt">aboot</Literal> image. Such a layout
|
|
can be achieved with the <Literal remap="tt">swriteboot</Literal> command. For example, to
|
|
setup a filesystem-less boot from <Literal remap="tt">/dev/sda</Literal>, one could use
|
|
the command:
|
|
|
|
<Screen>
|
|
# swriteboot /dev/sda bootlx vmlinux.gz
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
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).
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3>
|
|
<Title>Boot Flags</Title>
|
|
|
|
<Para>
|
|
A number of bootflags can be specified. The syntax is:
|
|
|
|
<Screen>
|
|
-flags "options..."
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
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:
|
|
</Para>
|
|
|
|
<Para>
|
|
<VariableList>
|
|
|
|
<VarListEntry>
|
|
<Term>load_ramdisk=1</Term>
|
|
<ListItem>
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>floppy=<Emphasis>str</Emphasis></Term>
|
|
<ListItem>
|
|
<Para>
|
|
Sets floppy configuration to <Emphasis>str</Emphasis>.
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>root=<Emphasis>dev</Emphasis></Term>
|
|
<ListItem>
|
|
<Para>
|
|
Select device <Emphasis>dev</Emphasis> 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.,
|
|
<Literal remap="tt">/dev/fd0</Literal>, <Literal remap="tt">/dev/sda2</Literal>).
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>single</Term>
|
|
<ListItem>
|
|
<Para>
|
|
Boot system in single user mode.
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
<VarListEntry>
|
|
<Term>kgdb</Term>
|
|
<ListItem>
|
|
<Para>
|
|
Enable kernel-gdb (works only if <Literal remap="tt">CONFIG_KGDB</Literal> is
|
|
enabled; a second Alpha system needs to be connected over the serial
|
|
port in order to make this work)
|
|
</Para>
|
|
</Listitem>
|
|
</VarListEntry>
|
|
</VariableList>
|
|
</Para>
|
|
|
|
<Para>
|
|
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, <Literal remap="tt">aboot</Literal> can be booted with the
|
|
single-character boot flag "i". With this flag, <Literal remap="tt">aboot</Literal> will
|
|
enter interactive mode
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3>
|
|
<Title>Using aboot interactively</Title>
|
|
|
|
<Para>
|
|
As of version 0.6, <Literal remap="tt">aboot</Literal> supports a simple command-oriented
|
|
interactive mode. Note that this is <Emphasis>different</Emphasis> 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:
|
|
|
|
<Screen>
|
|
>>> 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
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
<Sect3>
|
|
<Title>The aboot.conf configuration file</Title>
|
|
|
|
<Para>
|
|
Since booting in that manner quickly becomes tedious, <Literal remap="tt">aboot</Literal>
|
|
allows to define short-hands for frequently used command lines. In
|
|
particular, a single digit option (0-9) requests that <Literal remap="tt">aboot</Literal> uses
|
|
the corresponding option string stored in file
|
|
<Literal remap="tt">/etc/aboot.conf</Literal>. A sample <Literal remap="tt">aboot.conf</Literal> is shown below:
|
|
|
|
<Screen>
|
|
#
|
|
# 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
|
|
-
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
With this configuration file, the command
|
|
|
|
<Screen>
|
|
>>> boot dka0 -fl 1
|
|
</Screen>
|
|
|
|
corresponds exactly to the boot command shown above.
|
|
</Para>
|
|
|
|
<Para>
|
|
Finally, at the <Literal remap="tt">aboot</Literal> 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.
|
|
</Para>
|
|
|
|
<Sect4>
|
|
<Title>Selecting the Partition of /etc/aboot.conf</Title>
|
|
|
|
<Para>
|
|
When installed on a harddisk, <Literal remap="tt">aboot</Literal> needs to know what
|
|
partition to search for the <Literal remap="tt">/etc/aboot.conf</Literal> file. A newly
|
|
compiled <Literal remap="tt">aboot</Literal> will search the <Emphasis>second</Emphasis> partition (e.g.,
|
|
<Literal remap="tt">/dev/sda2</Literal>). Since it would be inconvenient to have to
|
|
recompile <Literal remap="tt">aboot</Literal> just to change the partition number,
|
|
<Literal remap="tt">abootconf</Literal> allows to directly modify an installed <Literal remap="tt">aboot</Literal>.
|
|
Specifically, if you want to change <Literal remap="tt">aboot</Literal> to use the <Emphasis>third</Emphasis>
|
|
partition on disk <Literal remap="tt">/dev/sda</Literal>, you'd use the command:
|
|
|
|
<Screen>
|
|
# abootconf /dev/sda 3
|
|
</Screen>
|
|
</Para>
|
|
|
|
<Para>
|
|
You can verify the current setting by simply omitting the partition
|
|
number. That is: <Literal remap="tt">abootconf /dev/sda</Literal> will print the currently
|
|
selected partition number. Note that <Literal remap="tt">aboot</Literal> does have to be
|
|
installed already for this command to succeed. As of version 0.6,
|
|
<Literal remap="tt">swriteboot</Literal> it will preserve the existing configuration when
|
|
installing a new <Literal remap="tt">aboot</Literal> on a hard disk.
|
|
</Para>
|
|
|
|
|
|
<Para>
|
|
Since <Literal remap="tt">aboot </Literal> version 0.5, it is also possible to select the
|
|
<Literal remap="tt"> aboot.conf </Literal> partition via the boot command line. This can be
|
|
done with a command line of the form <Emphasis remap="it">a</Emphasis><Literal remap="tt">:</Literal><Emphasis remap="it">b</Emphasis>
|
|
where <Emphasis remap="it">a</Emphasis>
|
|
is the partition that holds <Literal remap="tt">/etc/aboot.conf</Literal> and <Emphasis remap="it">b</Emphasis> is a
|
|
single-letter option as described above (<Literal remap="tt">0</Literal>-<Literal remap="tt">9</Literal>, <Literal remap="tt">i</Literal>, or
|
|
<Literal remap="tt">h</Literal>). For example, if you type <Literal remap="tt">boot -fl "3:h" dka100</Literal> the
|
|
system boots from SCSI ID 1, loads <Literal remap="tt">/etc/aboot.conf</Literal> from the
|
|
third partition, prints its contents on the screen and waits for you
|
|
to enter the boot options.
|
|
</Para>
|
|
|
|
</Sect4>
|
|
|
|
</Sect3>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2 id="DHCP-and-BOOTPD-server-setup">
|
|
<Title>Setting up a BOOTP capable server using DHCP</Title>
|
|
|
|
<Para>
|
|
The following configuration assumes that the server is running RH-6.2.
|
|
Prerequisites packages are,
|
|
<ItemizedList>
|
|
<Listitem>
|
|
<Para>
|
|
dhcp-2.0.5
|
|
</Para>
|
|
</Listitem>
|
|
<Listitem>
|
|
<Para>
|
|
tftp-server-0.16.5
|
|
</Para>
|
|
</Listitem>
|
|
</Itemizedlist>
|
|
|
|
</Para>
|
|
|
|
<Sect3>
|
|
<Title>DHCP & BOOTP configuation</Title>
|
|
<Para>
|
|
Once those packages are installed there are a few setup issues to take care of.
|
|
</Para>
|
|
|
|
<Para>
|
|
Create the default directory to which files will be pulled from using tftp.
|
|
</Para>
|
|
<Screen>
|
|
# mkdir /tftpboot
|
|
</Screen>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Screen>
|
|
# mkdir -p /var/state/dhcp
|
|
# touch /var/state/dhcp/dhcpd.leases
|
|
</Screen>
|
|
|
|
<Para>
|
|
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.
|
|
</Para>
|
|
|
|
<Screen>
|
|
#tftp dgram udp wait root /usr/sbin/tcpd in.tftpd
|
|
</Screen>
|
|
|
|
<Para>
|
|
Create the /etc/dhcp.conf configuation file. An example config
|
|
is provided below with the directives which allow BOOTP.
|
|
</Para>
|
|
|
|
<Screen>
|
|
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";
|
|
}
|
|
</Screen>
|
|
|
|
<Sect4>
|
|
<Title>Examination of /etc/dhcp.conf</Title>
|
|
<Para>
|
|
There are four directives that you should be concerned with.
|
|
</Para>
|
|
|
|
<ItemizedList>
|
|
<Listitem>
|
|
<Para><Literal remap="tt">range dynamic-bootp 192.168.1.3 192.168.1.254;</Literal>
|
|
which defines the range of ip's available for bootp.
|
|
</Para></Listitem>
|
|
<Listitem><Para>
|
|
<Literal remap="tt">allow bootp;</Literal>
|
|
which tells the dhcp server to allow the bootp protocol..
|
|
</Para></Listitem>
|
|
<Listitem><Para>
|
|
<Literal remap="tt">allow booting;</Literal>
|
|
which tells the dhcp server to allow the transfer of the file specified
|
|
either in the "filename" directive or passed in the "-file" flag in SRM.
|
|
</Para></Listitem>
|
|
<Listitem><Para>
|
|
<Literal remap="tt">filename "/tftpboot/vmlinux.bootp";</Literal>
|
|
which is the default file which is transferred and executed when no filename
|
|
specified in SRM as an argument.
|
|
</Para></Listitem>
|
|
</ItemizedList>
|
|
|
|
|
|
|
|
<Para>Lastly, Restart the inetd daemon so that the changes we made can take effect</Para>
|
|
|
|
<Screen># service inet restart</Screen>
|
|
|
|
<Para>You should now have a DHCP server that is capable of BOOTP.</Para>
|
|
</Sect4>
|
|
</Sect3>
|
|
|
|
<Sect3>
|
|
<Title id="bootpd-setup">bootpd configuration</Title>
|
|
<Para>
|
|
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
|
|
/tftpboot so copy bootpfile into /tftpboot .
|
|
|
|
</Para>
|
|
</Listitem>
|
|
</Orderedlist>
|
|
</Para>
|
|
</Sect3>
|
|
|
|
|
|
<Sect3>
|
|
<Title>Netboot using the aboot sources</Title>
|
|
<Para>
|
|
<OrderedList>
|
|
<Listitem>
|
|
<Para>
|
|
Build aboot with the command <Literal>make netboot</Literal>.
|
|
</Para>
|
|
</Listitem>
|
|
<Listitem>
|
|
<Para>
|
|
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
|
|
Linux scheme makes more sense, of course ;-).
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>Installing <Literal remap="tt">aboot</Literal></Title>
|
|
|
|
<Para>
|
|
<Emphasis>First big caveat</Emphasis>: with the SRM firmware, you can boot one and
|
|
only one operating system per disk. For this reason, it is generally
|
|
best to have at least two SCSI disks in a machine that you want to
|
|
dual-boot between Linux and DEC Unix. Of course, you could also boot
|
|
Linux from a floppy if speed doesn't matter or over the network, if
|
|
you have a <Literal remap="tt">bootp</Literal>-capable server. But in this section we assume
|
|
you want to boot Linux from a disk that contains one or more DEC Unix
|
|
partitions.
|
|
</Para>
|
|
|
|
<Para>
|
|
<Emphasis>Second big caveat</Emphasis>: installing <Literal remap="tt">aboot</Literal> on a disk shared with
|
|
DEC Unix renders the first and third partition unusable (since those
|
|
<Emphasis>must</Emphasis> have a starting offset of 0). For this reason, we recommend
|
|
that you change the size of partition <Literal remap="tt">a</Literal> to something that is just
|
|
big enough to hold <Literal remap="tt">aboot</Literal> (1MB should be plenty).
|
|
</Para>
|
|
|
|
<Para>
|
|
Once these two caveats are taken care of, installing <Literal remap="tt">aboot</Literal> is
|
|
almost as easy as usual: since partition <Literal remap="tt">a</Literal> and <Literal remap="tt">c</Literal> will
|
|
overlap with <Literal remap="tt">aboot</Literal>, we need to tell <Literal remap="tt">swriteboot</Literal> that this is
|
|
indeed OK. We can do this under Linux with a command line of the
|
|
following form (again, assuming we're trying to install <Literal remap="tt">aboot</Literal> on
|
|
the second SCSI disk):
|
|
|
|
<Screen>
|
|
# swriteboot -f1 -f3 /dev/sdb bootlx
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
The <Literal remap="tt">-f1</Literal> means that we want to force writing <Literal remap="tt">bootlx</Literal> even
|
|
though it overlaps with partition 1. The corresponding applies for
|
|
partition 3.
|
|
</Para>
|
|
|
|
<Para>
|
|
This is it. You should now be able to shutdown the system and boot
|
|
Linux from the harddisk. In our example, the SRM command line to do
|
|
this would be:
|
|
|
|
<Screen>
|
|
>>> boot dka5 -fi 8/vmlinux.gz -fl root=/dev/sdb8
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1>
|
|
<Title>Installation of Distributions</Title>
|
|
|
|
<Sect2>
|
|
<Title>RedHat 6.0, 6.1 and 6.2</Title>
|
|
|
|
<Sect3>
|
|
<Title>Installation from the Red Hat 6.0, 6.1 or 6.2 CD</Title>
|
|
|
|
<Para>
|
|
Red Hat have made their distribution CD bootable from SRM console
|
|
<FOOTNOTE>
|
|
|
|
<Para>
|
|
Please note that through the official RedHat CD-ROM is SRM
|
|
bootable, copies made by various other companies may not be
|
|
bootable.
|
|
</Para>
|
|
|
|
</FOOTNOTE>
|
|
|
|
To start an installation, put the CD in and type
|
|
the following:
|
|
|
|
<Screen>
|
|
>>> boot srm-device -file kernels/generic.gz -flags root=linux-device
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
In the above, the SRM device name and Linux device name for your
|
|
CD-ROM drive are needed. For Example if the machine had an IDE cdrom
|
|
installed as primary master the command would look like this:
|
|
|
|
<Screen>
|
|
>>> boot dqa0 -file kernels/generic.gz -flags "root=/dev/hda"
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
See the section on <XRef LinkEnd="device-naming"> conventions if you don't know what these are.
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>SuSE 6.1</Title>
|
|
|
|
<Sect3>
|
|
<Title>Installation from the SuSE 6.1 CD</Title>
|
|
|
|
<Para>
|
|
The SuSE 6.1 CD is not bootable from SRM console. SuSE have an
|
|
alternative approach which involves creating two boot floppies, the
|
|
images of which are included on the CD. The boot disks can be created
|
|
in various ways, depending on the systems you have available
|
|
</Para>
|
|
|
|
<Para>
|
|
Writing the boot disks from a linux system
|
|
The command to use is dd. From the mount-point of SuSE CD 1, the commands are:
|
|
|
|
<Screen>
|
|
# dd if=disks/aboot of=/dev/fd0
|
|
# dd if=disks/install of=/dev/fd0
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
For writing the boot disks from a windows system, the command to use
|
|
is rawrite. It is available on the CD.
|
|
|
|
<Screen>
|
|
D:\tools\> rawrite
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
The program then prompts for input disk image and output disk
|
|
drive. Run this command once for each of the disk images as shown
|
|
above.
|
|
</Para>
|
|
|
|
<Para>
|
|
Starting the SuSE installer from the boot disks
|
|
With the floppy disk made from the aboot image in place, type:
|
|
|
|
<Screen>
|
|
>>> boot dva0 -file vmlinux.gz -flags "root=/dev/fd0 load_ramdisk=1"
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
This will start the kernel, prompt you for the second boot disk, and start the installer
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
</Sect2>
|
|
|
|
<Sect2>
|
|
<Title>SuSE 6.3</Title>
|
|
|
|
<Sect3>
|
|
<Title>Installation from the SuSE 6.3 CD</Title>
|
|
|
|
<Para>
|
|
The SuSE 6.3 CD-ROM is SRM bootable much like the RedHat 6.0 and 6.1 CD-ROMs. The best way
|
|
to start the install from SRM is to use the following command:
|
|
|
|
<Screen>
|
|
>>> boot srm-device -flags 0
|
|
</Screen>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
In the above, the SRM device names for your
|
|
CD-ROM drive is needed. For Example if the machine had an IDE cdrom
|
|
installed as primary master the command would look like this:
|
|
|
|
<Screen>
|
|
>>> boot dqa0 -flags 0
|
|
</Screen>
|
|
|
|
SuSE has added support to aboot to allow it to load initrd files. The above command will from the
|
|
CD-ROM drive and use config number 0 from the /etc/aboot.conf file. For other variations
|
|
on this refer to the SuSE installation guide.
|
|
</Para>
|
|
|
|
</Sect3>
|
|
|
|
</Sect2>
|
|
|
|
</Sect1>
|
|
|
|
<Sect1>
|
|
<Title>Document History</Title>
|
|
<Para>
|
|
v0.8 9th November 2000 Changed from Rich Payne <rdp@alphalinux.org>
|
|
<ItemizedList>
|
|
<ListItem>
|
|
<Para>
|
|
Added section on SRM Device names
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Many spelling/grammer fixes.
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
</Para>
|
|
|
|
<Para>
|
|
v0.7.1 6th November 2000 Changes from Peter Petrakis <ppetrakis@alphalinux.org>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Cleaned up netbooting section. Avoid duplicate information.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Added DHCP/BOOTP server configuration section.
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Added SRM netbooting section.
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Put the older bootpd configuration in it's own section and elaborated on it.
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
</Para>
|
|
|
|
|
|
<Para>
|
|
v0.7 10th July 2000 Changes from Rich Payne <rdp@alphalinux.org>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Updated for RedHat 6.2
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Fixed aboot link for alphalinux.org and added CVS information.
|
|
</Para>
|
|
</ListItem>
|
|
|
|
<ListItem>
|
|
<Para>
|
|
Added additional netboot information from Peter Petrakis <ppetrakis@alphalinux.org>
|
|
</Para>
|
|
</ListItem>
|
|
</ItemizedList>
|
|
</Para>
|
|
|
|
|
|
<Para>
|
|
v0.6.1 21 March 2000 Changes from Rich Payne <rdp@alphalinux.org>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Made the installation hints a new chapter
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Added information on Netbooting
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Added to the new section on RedHat 6.1 and BSD disklabels
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Removed David Mosberger-Tang's name from the authors list
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Marked a few of the feature as being in 0.6 only
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Added info for SuSE 6.3 and RedHat 6.1
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
v0.6 3 March 2000 Changes and information from David Huggins-Daines
|
|
<dhd@linuxcare.com>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Moved the notes on MILO vs. SRM to an "About this document" section
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Added sections on switching to SRM, and basic SRM usage
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Added section on the new interactive use of aboot
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Updated the note on DOS partition tables to mention the Red Hat 6.1
|
|
installer's behavior.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Normalized the markup, and codified the conventions used for
|
|
user-entered commands.
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Corrected the notes on BSD disklabels (SRM does <Emphasis>not</Emphasis>
|
|
read BSD disklabels, it's just that they don't conflict with the boot
|
|
block).
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
v0.5.2 5 December 1999 Added comments and information from Stig Telfer
|
|
(stig @ alpha-processor.com).
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Added chart on SRM to Linux name mappings
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Added RedHat 6.0 and SuSE 6.1 installation information
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Added Disk Partitioning Information
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
v0.5.1 (Not Released) 13 November 1999 Took the original 0.5 document and updated several parts:
|
|
</Para>
|
|
|
|
<Para>
|
|
|
|
<ItemizedList>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Update information on SRM booting from IDE devices
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Fixed URL to aboot source
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Update toc page to reflect MILO's future
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Included information on bootdef_dev and boot_dev to chapter 3
|
|
</Para>
|
|
</ListItem>
|
|
<ListItem>
|
|
|
|
<Para>
|
|
Added this section
|
|
</Para>
|
|
</ListItem>
|
|
|
|
</ItemizedList>
|
|
|
|
</Para>
|
|
|
|
<Para>
|
|
v0.5 17 August 1996 - Original Document by David Mosberger-Tang
|
|
</Para>
|
|
|
|
</Sect1>
|
|
|
|
</Article>
|