This chapter begins with some general information about booting Debian GNU/Linux, then moves to individual sections on particular installation methods, and concludes with some troubleshooting advice.
Boot parameters are Linux kernel parameters which are generally used to make sure that peripherals are dealt with properly. For the most part, the kernel can auto-detect information about your peripherals. However, in some cases you'll have to help the kernel a bit.
Depending on the console firmware from which you will be bootstrapping,
different methods apply for passing parameters to the kernel. These methods
will be described below, separately for each bootstrap procedure. Full
information on boot parameters can be found in the Linux BootPrompt
HOWTO; this section contains only a sketch of the most salient
parameters.
If this is the first time you're booting the system, try the default boot parameters (i.e., don't try setting arguments) and see if it works correctly. It probably will. If not, you can reboot later and look for any special parameters that inform the system about your hardware.
When the kernel boots, a message Memory: availk/totalk available should be emitted early in the process. total should match the total amount of RAM, in kilobytes. If this doesn't match the actual of RAM you have installed, you need to use the mem=ram parameter, where ram is set to the amount of memory, suffixed with ``k'' for kilobytes, or ``m'' for megabytes. For example, both mem=65536k and mem=64m mean 64MB of RAM.
If your monitor is only capable of black-and-white, use the mono boot argument. Otherwise, your installation will use color, which is the default.
If you are booting with a serial console, generally the kernel will autodetect this. If you have a videocard (framebuffer) and a keyboard also attached to the computer which you wish to boot via serial console, you may have to pass the console=device argument to the kernel, where device is your serial device, which is usually something like ``ttyS0''.
Again, full details on boot parameters can be found in the Linux BootPrompt
HOWTO, including tips for obscure hardware. Some common gotchas are
included below in Troubleshooting the Boot
Process, Section 6.10.
The installation system recognizes a few arguments which may be useful.
During the boot sequence, you may see many messages in the form can't find something, or something not present, can't initialize something, or even this driver release depends on something. Most of these messages are harmless. You see them because the kernel for the installation system is built to run on computers with many different peripheral devices. Obviously, no one computer will have every possible peripheral device, so the operating system may emit a few complaints while it looks for peripherals you don't own. You may also see the system pause for a while. This happens when it is waiting for a device to respond, and that device is not present on your system. If you find the time it takes to boot the system unacceptably long, you can create a custom kernel later (see Compiling a New Kernel, Section 8.4).
In some cases, you may wish to boot from an existing operating system. You can also boot into the installation system using other means, but install the base system from disk.
You can install Debian from an ext2fs partition or from a Minix partition. This installation technique may be appropriate if you are completely replacing your current Linux system with Debian, for instance.
Note that the partition you are installing from should not be the same
as the partitions you are installing Debian to (e.g., /,
/usr, /lib, etc.).
To install from an already existing Linux partition, follow these instructions.
http://http.us.debian.org/debian/dists/potato/main/disks-alpha/current/base2_2.tgz
If you have a CD which is bootable, and if your architecture and system supports booting from a CD-ROM, you don't need any floppies. Booting from CD-ROM on Alpha is somewhat more involved than on i386. However, the reduction in the number of floppies required makes it worthwhile. See Booting the Installation System, Chapter 6 for more information on booting Alpha systems from CD and floppy.
Even if you cannot boot from CD-ROM, you can install the base Debian system from CD-ROM. Simply boot using a different media, such as floppies. When it is time to install the base system and any additional packages, point the installation system at the CD-ROM drive as described in ``Install the Base System'', Section 7.14.
You need to setup a BOOTP server and a TFTP server.
BOOTP is an IP protocol that informs a computer of its IP address and where on the network to obtain a boot image. Unlike the Open Firmware found on Sparc and PowerPC machines, the SRM console will not use RARP to obtain its IP address, and therefore you must use BOOTP for netbooting your Alpha. You can also enter the IP configuration for network interfaces directly in the SRM console. [3]
The Trivial File Transfer Protocol (TFTP) is used to serve the boot image to the client. Theoretically, any server, on any platform, which implements these protocols, may be used. In the examples in this section, we shall provide commands for SunOS 4.x, SunOS 5.x (a.k.a. Solaris), and GNU/Linux.
There are two BOOTP servers available for GNU/Linux, the CMU bootpd and the ISC
dhcpd, which are contained in the bootp and dhcp
packages on Debian GNU/Linux.
To use CMU bootpd, you must first uncomment (or add) the relevant line in
/etc/inetd.conf. On Debian GNU/Linux, you can run
update-inetd --enable bootps, then /etc/init.d/inetd
reload to do so. Elsewhere, the line in question should look like:
bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120
Now, you must create an /etc/bootptab file. This has the same
sort of familiar and cryptic format as the good old BSD
printcap(5), termcap(5), and disktab(5)
files. See the bootptab(5) manual page for more information. For
CMU bootpd, you will need to know the hardware (MAC) address of the client.
By contrast, setting up BOOTP with ISC dhcpd is really easy,
because it treats BOOTP clients as a moderately special case of DHCP clients.
You don't really need to know the hardware (MAC) address of the client unless
you wish to specify some options such as boot image filename or NFS root path
on a client-by-client basis, or unless you wish to assign fixed addresses to
your machines using BOOTP and/or DHCP. Simply add the allow bootp
directive to the configuration block for the subnet containing the client, and
restart dhcpd with /etc/init.d/dhcpd restart.
To get the TFTP server ready to go, you should first make sure that
tftpd is enabled. This is usually enabled by having the following
line in /etc/inetd.conf:
tftp dgram udp wait root /usr/etc/in.tftpd in.tftpd /tftpboot
Look in that file and remember the directory which is used as the argument of
in.tftpd; you'll need that below. The -l argument
enables some versions of in.tftpd to log all requests to the
system logs; this is useful for diagnosing boot errors. If you've had to
change /etc/inetd.conf, you'll have to notify the running
inetd process that the file has changed. On a Debian machine, run
/etc/init.d/netbase reload (for potato/2.2 and newer systems use
/etc/init.d/inetd reload); on other machines, find out the process
ID for inetd, and run kill -HUP inetd-pid.
Next, place the TFTP boot image you need, as found in Description of Installation
System Files, Section 5.4, in the tftpd boot image directory.
Generally, this directory will be /tftpboot. Next you'll have to
make a link from that file to the file which tftpd will use for
booting a particular client. Unfortunately, the file name is determined by the
TFTP client, and there are no strong standards.
Often, the file that the TFTP client will look for is
client-ip-in-hexclient-architecture. To compute
client-ip-in-hex, take each byte of the client IP address and
translate it into hexadecimal notation. If you have a machine handy with the
bc program, you can use the program. First issue the
obase=16 command to set the output to hex, then enter the
individual components of the client IP one at a time. As for
client-architecture, try out some values.
On Alpha, you must specify the filename (as a relative path to the boot image directory) using the -file argument to the SRM boot command, or by setting the BOOT_FILE environment variable. Alternatively, the filename can be given via BOOTP (in ISC dhcpd, use the filename directive). Unlike Open Firmware, there is no default filename on SRM, so you must specify a filename by either one of these methods.
Once you've determined the name, make the link like this: ln /boot/tftpboot.img /boot/file-name.
Now you should be ready to actually boot your system. In SRM, Ethernet interfaces are named with the ewa prefix, and will be listed in the output of the show dev command, like this (edited slightly):
>>>show dev
ewa0.0.0.9.0 EWA0 08-00-2B-86-98-65
ewb0.0.0.11.0 EWB0 08-00-2B-86-98-54
ewc0.0.0.2002.0 EWC0 00-06-2B-01-32-B0
So, to boot from the first Ethernet interface, you would type:
>>>boot ewa0
If you wish to use a serial console, you must pass the console= parameter to the kernel. This can be done using the -flags argument to the SRM boot command. The serial ports are named the same as their corresponding files in /dev. For example, to boot from ewa0 and use a console on the first serial port, you would type:
>>>boot ewa0 -flags console=ttyS0
NOT YET WRITTEN
It is closer to "tftp install for lowmem..." because you don't want to load the ramdisk anymore but boot from the newly created nfs-root fs. You then need to replace the symlink to the tftpboot image by a symlink to the kernel image (eg. linux-a.out). My experience on booting over the network was based exclusively on RARP/TFTP which requires all daemons running on the same server (the sparc workstation is sending a tftp request back to the server that replied to its previous rarp request). However, Linux supports BOOTP protocol, too, but I don't know how to set it up :-(( Does it have to be documented as well in this manual?
Console firmware is stored in a flash ROM and started when an Alpha system is powered up or reset. There are two different console specifications used on Alpha systems, and hence two classes of console firmware available:
From the user's perspective, the most important difference between SRM and ARC is that the choice of console constrains the possible disk-partitioning scheme for the hard disk which you wish to boot off of.
ARC requires that you use an MS-DOS partition table (as created by
cfdisk) for the boot disk. Therefore MS-DOS partition tables are
the ``native'' partition format when booting from ARC. In fact, since
AlphaBIOS contains a disk partitioning utility, you may prefer to partition
your disks from the firmware menus before installing Linux.
Conversely, SRM is incompatible with MS-DOS partition tables. [4] Since Tru64 Unix uses the BSD disklabel format, this is the ``native'' partition format for SRM installations.
Because GNU/Linux is the only operating system on Alpha that can be booted from both console types, the choice will also depend on what other operating systems you wish to run on the same machine. All other Unix-like operating systems (Tru64 Unix, FreeBSD, OpenBSD, and NetBSD) and OpenVMS can only boot from SRM, whereas Windows NT can only boot from ARC.
The following table summarizes available and supported system type/console combinations (see CPU, Mainboards, and Video Support, Section 2.1.2 for the system type names). The word `ARC' below denotes any of the ARC-compliant consoles.
System Type Console Type Supported
=========== ======================
alcor ARC or SRM
avanti ARC or SRM
book1 SRM only
cabriolet ARC or SRM
dp264 SRM only
eb164 ARC or SRM
eb64p ARC or SRM
eb66 ARC or SRM
eb66p ARC or SRM
jensen SRM only
lx164 ARC or SRM
miata ARC or SRM
mikasa ARC or SRM
mikasa-p SRM only
nautilus ARC only (see motherboard manual)
noname ARC or SRM
noritake SRM only
noritake-p SRM only
pc164 ARC or SRM
rawhide SRM only
ruffian ARC only
sable SRM only
sable-g SRM only
sx164 ARC or SRM
takara ARC or SRM
xl ARC only
xlt ARC or SRM
Generally, none of these consoles can boot Linux directly, so the assistance of
an intermediary bootloader is required. There are two mainstream Linux
loaders: MILO and aboot.
MILO is itself a console, which replaces ARC or SRM in memory.
MILO can be booted from both ARC and SRM and is the only way to
bootstrap Linux from the ARC console. MILO is platform-specific
(a different MILO is needed for each system type) and exist only
for those systems, for which ARC support is shown in the table above. See also
the (unfortunately outdated) MILO HOWTO.
aboot is a small, platform-independent bootloader, which runs from
SRM only. See the (also unfortunately outdated) SRM HOWTO for more
information on aboot.
Thus, three scenarios are generally possible, depending on the system's console
firmware and whether or not MILO is available:
SRM -> aboot
SRM -> MILO
ARC -> MILO
The UP1000 motherboard (subarchitecture name `nautilus') from Alpha Processor, Inc. is different from all the others, in that it uses an API-specific bootloader that runs under AlphaBIOS firmware. There are no install disks (yet) for the UP1000, but you should be able to install by booting a `generic' or `nautilus' kernel with the root.bin from the install disks, following the instructions in the manual.
Because MILO is not available for any of the Alpha systems
currently in production (as of February 2000), and because it is no longer
necessary to buy an OpenVMS or Tru64 Unix license to have SRM firmware on your
older Alpha, it is recommended that you use SRM and aboot on new
installations of GNU/Linux, unless you wish to dual-boot with Windows NT, or
you have existing DOS-partitioned disks.
The majority of AlphaServers and all current server and workstation products contain both SRM and AlphaBIOS in their firmware. For "half-flash" machines such as the various evaluation boards, it is possible to switch from one version to another by reflashing the firmware. Also, once SRM is installed, it is possible to run ARC/AlphaBIOS from a floppy disk (using the `arc' command).
As on other architectures, you should install the newest available revision of
the firmware [5] before installing
Debian. For Alpha, firmware updates can be obtained from Alpha Firmware
Updates.
At the SRM prompt (>>>), issue the following command:
>>> boot dva0 -flags 0
possibly replacing dva0 with the actual device name. Usually,
dva0 is the floppy; type
>>> show dev
to see the list of devices (e.g., if you want to boot from a CD). Note that if
you are booting via MILO, -flags argument is ignored, so you can
just type boot dva0.
If everything works OK, you will eventually see the Linux kernel boot.
If you want to specify kernel parameters when booting via aboot,
use the following command:
>>> boot dva0 -file linux.gz -flags
"root=/dev/fd0 load_ramdisk=1 arguments"
(typed on one line), substituting, if necessary, the actual SRM boot device
name for dva0, the Linux boot device name for fd0,
and the desired kernel parameters for arguments.
If you want to specify kernel parameters when booting via MILO,
you will have to interrupt bootstrap once you get into MILO. See Booting with MILO, Section
6.9.
In the OS Selection menu, set linload.exe as the boot loader, and
milo as the OS Path. Bootstrap using the newly created entry.
To bootstrap the installation system, enter the following command at the MILO prompt:
MILO> boot fd0:linux.gz root=/dev/fd0 load_ramdisk=1
If you are booting from something other than a floppy, substitute
fd0 in the above example with the appropriate device name in Linux
notation. The help command would give you a brief MILO command
reference.
If you have problems and the kernel hangs during the boot process, doesn't recognize peripherals you actually have, or drives are not recognized properly, the first thing to check is the boot parameters, as discussed in Boot Parameter Arguments, Section 6.1.
Often, problems can be solved by removing add-ons and peripherals, and then trying booting again.
If you still have problems, please submit a bug report. Send an email to
submit@bugs.debian.org. You
must include the following as the first lines of the email:
Package: boot-floppies
Version: version
Make sure you fill in version with the version of the boot-floppies set that you used. If you don't know the version, use the date you downloaded the floppies, and include the distribution you got them from (e.g., ``stable'', ``frozen'').
You should also include the following information in your bug report:
architecture: alpha
model: your general hardware vendor and model
memory: amount of RAM
scsi: SCSI host adapter, if any
cd-rom: CD-ROM model and interface type, e.g., ATAPI
network card: network interface card, if any
pcmcia: details of any PCMCIA devices
Depending on the nature of the bug, it also might be useful to report whether you are installing to IDE or SCSI disks, other peripheral devices such as audio, disk capacity, and the model of video card.
In the bug report, describe what the problem is, including the last visible kernel messages in the event of a kernel hang. Describe the steps that you did which brought the system into the problem state.