vbatts/elilo
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

release 3.4

Browse source 
https://sourceforge.net/projects/elilo/files/elilo/elilo-3.4/
This commit is contained in:
Stephane Eranian 2004-02-23 08:11:30 -05:00 • committed by Vincent Batts
commit fb6ce0d596
100 changed files with 20247 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

106
docs/devschemes.txt Normal file
View file

@ -0,0 +1,106 @@
Some explanations of what the devschemes are for:
-------------------------------------------------
Copyright (c) 2001-2003 Hewlett-Packard Co
Contributed by Stephane Eranian <eranian@hpl.hp.com>
Whether or not EDD3.0 is enabled, EFI uses a device naming scheme which is
somewhat detailed. It tries to follow the hardware path from the System bus
down to the actual partition on the media. The following example shows
a typical block device path from a SCSI disk:
blk2 : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig00000000).
Elilo allows the user to load files from any device. This means that it
must provide a way for the user to specify a file path which include
the device name. While it is theoritically possible to specify the
path mentioned above, it is far from practical because the names
are too long. There is too much details which the user (especially of
a boot loader) does not care about.
So Elilo, just like the EFI shell, must have a way of assigning logical
names to device names (paths). The EFI shell uses the fsX notation wherever
it finds a block devices for which it has detected a valid EFI filesystem
(i.e. a Fat32+ filesystem). This assignment is done on the fly, and depending
on the status of the removable media (like CDROM or floppy) the mapping can
change.
Those fsX: names are a pure abstraction of the EFI shell and have nothing to
do with the EFI specification.
Now Elilo could try to emulate then, i.e. try to reproduce the way the EFI shell
assigns names. However the problem is that, AT THIS POINT, Elilo recognized more
device from which it can load files from than the Shell does. This comes from the
fact that it can load files from the network or from an Ext2fs, for instance.
We plan on fixing those issues in the next releases of Elilo. Anyway, the problem
would still be to make sure that if we follow the same naming scheme, they match
at all times, i.e. fs0: maps to the same device in both the EFI shell and Elilo
which may be tricky as both EFI and Elilo continue to evolve. Also the Shell
naming schemes as some problems which removable devices which would not make it
easy from the bootloader.
Another possible solution would be to use the Linux kernel naming scheme, i.e.,
hda, hda1, fd0, sda... Of course, we would drop the /dev prefix in this case.
While it would make it very convenient for users and easy to configure from
a running system, it is even more difficult that the EFI Shell scheme. Again,
to succeed, the loader scheme would have to match EXACTLY what the Linux kernel
does for all possible devices. This is a very complicated task as his any
naming problem. The recent discussions about the devfs support in the kernel is
just yet another proof of the complexity. Another issue here is that this would
create a dependency between the loader and the kernel because we would need the
way the naming is done in the kernel. Again, this is very complicated, just thinnking
about how the PCI buses are scanned looking from devices.
So it looks like there is single solutions. Clearly, that is not easy and there are
multiple schemes possible. For now, we felt that it was better for Elilo to use its
own naming scheme independent from the EFI shell and the Linux kernel. While this introduces
yet another scheme, we believe its advantages outweight the software complexity associated
with the two schemes described above.
However, we recognize the need for flexibilty and that is exactly why, this version
of Elilo provide an internal interface which can used to develop custom naming schemes.
The way the filepaths are translated by Elilo is very basic and based on a simple
string matching algorithm. A full pathname is specified as follows:
dev_name:/path/to/my/file.
The 'dev_name' is created by Elilo and can be anything relevant to the user. There is
an internal binding from the name to the actual EFI device handle and more precisely
the filsystem interface associated to it (the device handle is never exposed to the
boot loader).
By default, Elilo uses an extremely simple scheme which is similar to the EFI shell.
if simply builds the device names as follows:
devXXX.
The XXX is just the number of the device. It is incremented by one each time recognized
filesystem is detected on that device. The clear advantage is simplicity. The downside
is that is creates a 'flat' namespace where every new device detected (like a floppy
is inserted) will show up anywhere in the set of devices and may push some fixed
devices up or down. So it hard to rely on devXXX to always mean the same things.
Now custom naming schemes can be added on top of this, which would partially or totally
replace this default scheme. Elilo is shipped with one such scheme called 'simple'.
It provides an example of how one can develop a new scheme. The main characteristic
of 'simple' is that it tries to group devices by controller (Messaging Device in
EFI terminology). Hence, all the ATAPI devices show up as atapiXXX and the SCSI
device show up as SCSIXXX. This implicitely shields the SCSI (fixed most likely) devices
from the removable media coming from ATAPI (like floppy or CDROM). So it is slightly
better but far from perfect.
Here is an example of what it looks like on an actual system:
scsi0 : vfat : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig00000000)
scsi1 : vfat : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun6,Lun0)/HD(Part1,Sig00000000)
atapi0 : vfat : Acpi(PNP0A03,0)/Pci(3|1)/Ata(Secondary,Master)/CDROM(Entry1)
scsi2 : ext2fs : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun0,Lun0)/HD(Part2,Sig00000000)
scsi3 : ext2fs : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun6,Lun0)/HD(Part2,Sig00000000)
net0 : netfs : Acpi(PNP0A03,0)/Pci(5|0)/Mac(00D0B7A6FC25)
The 'simple' scheme is not fully satifactory but developers are strongly encouraged
to enhance it or better create new schemes.

102
docs/edd30.txt Normal file
View file

@ -0,0 +1,102 @@
Information related to EDD3.0 and ELILO
---------------------------------------
Last updated: 02/02/14
As of elilo-3.0, the filesystem/device naming scheme takes advantage
of the EDD3.0 support present in the underlying EFI/BIOS firmware layers.
The EDD3.0 support is supposedly turned on by default in all version of the
EFI firmware on IA-64 (and possibly IA-32).
Support can be enabled or disabled dynamically using an EFI environment
variable called "EDD30". The GUID of the variable is as follows:
#define EDD30_GUID \
{0x964e5b21, 0x6459, 0x11d2, { 0x8e, 0x39, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b}}
This is a boolean variable. When true, support is enabled.
You can check if support is enabled by typing:
Shell> edd30
Usage edd30 [On | Off]
Used to support OS Loader debug
EDD30 DevicePath Mode is On
at this EFI shell prompt. You can enable support by forcing the variable
to TRUE. This can be accomplished by typing:
Shell> edd30 on
EDD30 DevicePath Mode is On
Alternatively an EFI application can use RT->SetVariable() to set the
value of the EDD30 variable.
If the variable was set to false, then to take advantage of EDD3.0
support after switching the variablle to TRUE, the system MUST be
rebooted as EDD affects the core of EFI naming scheme.
Elilo will check if the variable is defined and valid. If it is set
to true, then the device name schemes that rely on it will work properly.
That's the case for the 'simple' scheme. If the variable is not set to true
or does not exist, elilo will use a generic builtin scheme with names
such as dev001, dev002 and so on. The "EDD30" variable is like a system
variable therefore it is expected not to be overloaded by users for others
purposes. Elilo is fully functional even when EDD30 is off.
By default, if EDD30 is off, elilo will try and set the variable to TRUE.
However, some controllers do not support EDD30 and forcing the variable
may cause problems. Therefore as of elilo-3.2, there is an option to
avoid forcing the variable. In the config file, you can use 'noedd30' option
and on the command line, you can use the -E option.
When the variable is forced back to TRUE, th effect will only be seen after
a reboot. Shall you decide not to reboot immediately, elilo
will system still operate using the generic naming scheme.
When EDD3.0 is enabled the output of the EFI shell 'map' command looks similar
to this:
Device mapping table
fs0 : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig00000000)
fs1 : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun6,Lun0)/HD(Part1,Sig00000000)
fs2 : Acpi(PNP0A03,0)/Pci(3|1)/Ata(Secondary,Master)/CDROM(Entry1)
blk0 : Acpi(PNP0A03,0)/Pci(3|1)/Ata(Primary,Master)
blk1 : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun0,Lun0)
blk2 : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig00000000)
blk3 : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun0,Lun0)/HD(Part2,Sig00000000)
blk4 : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun0,Lun0)/HD(Part3,Sig00000000)
blk5 : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun6,Lun0)
blk6 : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun6,Lun0)/HD(Part1,Sig00000000)
blk7 : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun6,Lun0)/HD(Part2,Sig00000000)
blk8 : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun6,Lun0)/HD(Part3,Sig00000000)
blk9 : Acpi(PNP0A03,2)/Pci(0|0)/Scsi(Pun6,Lun0)/HD(Part3,Sig00000000)/HD(Part1,Sig00000200)
blkA : Acpi(PNP0A03,0)/Pci(3|1)/Ata(Secondary,Master)
blkB : Acpi(PNP0A03,0)/Pci(3|1)/Ata(Secondary,Master)/CDROM(Entry1)
Shell>
The same system with EDD3.0 disabled will look like this:
Device mapping table
fs0 : VenHw(Unknown Device:80)/HD(Part1,Sig00000000)
fs1 : VenHw(Unknown Device:81)/HD(Part1,Sig00000000)
fs2 : VenHw(Unknown Device:FF)/CDROM(Entry1)
blk0 : VenHw(Unknown Device:00)
blk1 : VenHw(Unknown Device:80)
blk2 : VenHw(Unknown Device:80)/HD(Part1,Sig00000000)
blk3 : VenHw(Unknown Device:80)/HD(Part2,Sig00000000)
blk4 : VenHw(Unknown Device:80)/HD(Part3,Sig00000000)
blk5 : VenHw(Unknown Device:81)
blk6 : VenHw(Unknown Device:81)/HD(Part1,Sig00000000)
blk7 : VenHw(Unknown Device:81)/HD(Part2,Sig00000000)
blk8 : VenHw(Unknown Device:81)/HD(Part3,Sig00000000)
blk9 : VenHw(Unknown Device:81)/HD(Part3,Sig00000000)/HD(Part1,Sig00000200)
blkA : VenHw(Unknown Device:FF)
blkB : VenHw(Unknown Device:FF)/CDROM(Entry1)
Shell>
EDD3.0 is an industry standard and the working draft can be downloaded from the
following web site:
http://www.t13.org/
The document reference is D1386 (Enhanced Disk Drive Services 3.0).

478
docs/elilo.txt Normal file
View file

@ -0,0 +1,478 @@
--------------------------------------------------------------------
ELILO.EFI: Linux boot loader for EFI/IA-64 and EFI/IA-32 based systems
--------------------------------------------------------------------
Stephane Eranian <eranian@hpl.hp.com>
August 2003
Copyright (C) 2000-2003 Hewlett-Packard Co.
I/ Introduction
------------
This document describes how to use ELILO on for both IA-64 and IA-32 EFI-based platforms.
This document describes ELILO version 3.4.
II/ Command line options
--------------------
elilo [-hDpPVvaE] [-d nsec] [-C config] [-i initrd] [-c chooser] [kernel [kernel options...]]
-h Display a list of all possible command line options.
-V Print the version number and exit.
-d nsec Specify the number of 10th of seconds before loading the
kernel.
-C file Specify the config file to use. The default is elilo.conf in the directory
that elilo.efi was loaded from.
-P Verify config file syntax only. this option causes ELILO to
parse the config file and generate a report on the console.
No kernel is loaded.
-v Turn on verbose mode. ELILO prints more message about what it
is doing. For each occurrence of this option the verbosity level
is increased by one. The maximum level is 5.
-a Always check for alternate kernel image. The default behavior
of ELILO is to NOT look for an alternate image. This
option overrides this behavior and ELILO is checking for
alternate images no matter what. Alternate images are
specified using the EliloAlt EFI variable.
-p force interactive prompt mode. Valid when no kernel image is
specified on the command line.
-D print debug output.
-E don't force EDD30 variable to TRUE when FALSE.
-i file Use file as the initial ramdisk (initrd).
-c name Specify which kernel chooser to use. Default is 'simple', and
the only other choice at present is 'textmenu'.
In addition, elilo supports platform specific options:
For IA-64:
----------
-r the kernel image can be relocated if initial load address is not
available. This options requires a special version of the kernel.
-F file will try to load the FPSWA driver indicated by 'file'. Only this file
will be attempted. When no specific file is given, elilo will try
loading \efi\intel firmware\fpswa.efi from all accessible EFI system
partitions.
For IA-32:
----------
no option defined.
All file names (including the kernel file) can include a device name using the
following syntax:
dev_name:/path/to/my/kernel
The 'dev_name' component depends on the naming scheme selected and the detected
devices for your system. Some choosers may print the information automatically
or on demand, see chooser specific documentation for more on this. See README.devschemes
for more information on device naming schemes. The slash character '/' can be used as
a directory separator on any file systems including the EFI file system (FAT32).
III/ Configuration File
------------------
ELILO supports a config file with options similar to the LILO/x86 boot loader.
Elilo will use the following sequence (shown in order) when looking for its config
file when none is specified on the command line:
1/ AABBCCDD.conf (netbooting with regular DHCP)
where AABBCCDD is the hexadecimal representation
of the IP address assigned during the DHCP phase.
2/ elilo-ia64.conf or elilo-ia32.conf
The choice depends on the client platform. This step allows
the same DHCP/PXE server to provide files for both types of clients.
3/ elilo.conf
Unless explicitly specified on the command line, elilo looks for its config file
in the filesystem and directory it was loaded from. For instance, if elilo.efi
is invoked as:
fs0:\> \efi\debian\elilo.efi
Then elilo will look for its configuration file in fs0:\efi\debian and not
in the root directory of fs0:. The prefix fs0:\efi\debian will be used for
all other files that elilo needs to download when their paths are specified
as being relative.
IMPORTANT:
This rule also applies when a specific config file is passed via the -C
option. For example:
fs0:\> \efi\debian\elilo.efi -C elilo.conf
This will look for elilo.conf in fs0:\efi\debian and not in fs0:\.
To get to the elilo.conf in fs0:\, you need to specify the absolute
path:
fs0:\> \efi\debian\elilo.efi -C \elilo.conf
The configuration file is an ASCII file and not a UNICODE file.
The config file contains additional options to change the behavior of the loader.
If the same option is specified in the config file AND on the command line, the
latter takes precedence. Not all options available in the config file have an
equivalent on command line.
When elilo is invoked with the -h option, it prints the list of support command line
options but also the list of config file options. For each option it also prints
the type of data expected.
The config file options are divided in 2 groups:
- image options which are specific to a particular kernel image. Each kernel image
must be identified with a logical name called a label.
- global options which affect the behavior of ELILO and apply to all images.
The ELILO config file follows the LILO/x86 syntax. First come the global
options, then the list of images and options for each of them, if
necessary. At least one image MUST be defined and it is possible to have
an empty list of global options.
Options have types. Three types are defined:
- boolean: set or not set
- string : a string of characters which can be quoted if necessary
- number (in decimal)
- filename: a string interpreted as a file name
The config file supports the following options:
Global Options:
---------------
default=value Name the default image to boot. If not defined ELILO
will boot the first defined image.
timeout=number The number of 10th of seconds to wait while in
interactive mode before auto booting default kernel.
Default is infinity.
delay=number The number of 10th of seconds to wait before
auto booting when not in interactive mode.
Default is 0.
prompt Force interactive mode
verbose=number Set level of verbosity [0-5]. Default 0 (no verbose)
root=filename Set global root filesystem for Linux/ia64
read-only Force root filesystem to be mounted read-only
append=string Append a string of options to kernel command line
initrd=filename Name of initrd file
image=filename Define a new image
chooser=name Specify kernel chooser to use: 'simple' or 'textmenu'.
message=filename a message that is printed on the main screen if supported by
the chooser.
fX=filename Some choosers may take advantage of this option to
display the content of a file when a certain function
key X is pressed. X can vary from 1-12 to cover
function keys F1 to F12.
noedd30 do not force the EDD30 EFI variable to TRUE when FALSE. In other
words, don't force the EDD30 mode if not set.
Image options:
--------------
root=filename Set root filesystem for kernel
read-only Force root filesystem to be mounted read-only
append=string Append a string of options to kernel command line
initrd=filename Name of initrd file
label=string Logical name of image (used in interactive mode)
description=string One line text description of the image.
IA-64 specific options:
-----------------------
Global options:
---------------
fpswa=file Specify the filename for a specific FPSWA to load.
If this option is used then no other file will be tried.
relocatable In case of memory allocation error at initial load point of
kernel, allow attempt to relocate (assume kernels is relocatable)
Image options:
--------------
relocatable In case of memory allocation error at initial load point of
kernel, allow attempt to relocate (assume this kernel is relocatable)
IA-32 specific options:
-----------------------
legacy-free Indicate that the host machine does not have a legacy BIOS at all.
The user can specify a kernel and related kernel options using the image label. Alternatively,
the user can also specify a kernel file that is not specified in the config file. In any case,
some of the global options (such as append) are always concatenated to whatever the user type.
IV/ Booting from the local system
-----------------------------
The elilo.efi binary must be in an EFI system partition (FAT32). The config
file, kernel image, and optional initrd ramdisk can be on the same partition
or even another EFI partition. In the following discussion we assume that all
files are on the same EFI partition which is recognized by the EFI shell (nshell)
as fs0. The kernel and initrd can be copied from the any linux filesystems to the
EFI partition using either the mtools (mcopy) or by mounting the EFI partition as
a vfat partition. However you do not really need this because most linux
distributions install both files in the EFI partition and mount this partition in /boot/efi.
To boot a kernel, simply power cycle the machine. Once you get to the EFI
shell prompt, change to the filesystem that maps to the partition where elilo is.
Shell> fs0:
fs0:\>
You might need to make sure that the Shell Path is set such that it will load
ELILO from fs0:. You can verify this by typing:
fs0:\> set
path : fs0:\
At this point you can invoke ELILO:
fs0:\> elilo
If there is no config file, then it will:
- pick up the kernel image named vmlinux if it exists, otherwise it will abort.
- pass no argument to the kernel.
You can specify the kernel image and its options on the command line.
For instance you can do:
fs0:\> elilo vmlinux root=/dev/sda5
You can specify as many parameters as you want. The syntax follows the kernel
rule, i.e., list of value pairs (or even single values) separated by space.
A more complicated example would be:
fs0:\> elilo -i initrd-2.4.9 vmlinuz-2.4.9 root=/dev/sda2 console=tty0 console="ttyS0,115200n8"
In this example, notice the double quotes. They are required because the comma is a control
character for nshell.
In the case a config file is found, then elilo will behave according to
the options in that file. However if elilo is invoked with command line options, they
will be combined or they will override (if conflicting) what is defined in the config file.
As of version 3.3, elilo is fully compliant with the EFI specification (1.10) with regards
to where the bootloader (elilo.efi) must be located in the EFI system partition. In
section 11.2.1.3 of the EFI1.10 specification, it is said that in order to avoid conflicts
between various loaders for various OSes or distributions of the same OS, every vendor MUST
use a dedicated directory: \EFI\vendor\. The bootloader must be placed in this directory.
This has always been possible as this is a matter of creating the directory and copying
the elilo.efi file in it. However up until version 3.3, elilo would look for its config file
and kernel/initrd in the root (/) of the partition it was loaded from. As of version 3.3,
elilo will now ONLY look for its configuration file FROM THE DIRECTORY IT WAS LOADED FROM.
The same applies to the kernel and initrd files unless absolute paths are specified. Let us
look at a simple example:
- suppose elilo.efi is in \EFI\DIST if fs0: (for the EFI Shell)
- if you invoke elilo as follows:
fs0:\> \efi\dist\elilo -v -p
default file path: \efi\dist\
config file : \efi\dist\elilo.conf
ELILO boot:
Note that this is the same if you invoke elilo directly from \efi or \efi\dist.
File references in the configuration file are treated as relative to the directory
elilo was loaded from except if they use an absolute path.
As of version 3.4 a similar rule applies to the network boot sequence, see netbooting.txt
for details.
V/ Interactive mode
----------------
Elilo can be forced into interactive mode using the "prompt" option in the config
file or with the -p option. In this mode, the user can select a kernel to load.
The interface depends on the chooser, it may be a simple command line prompt as provided
by the simple chooser or a more sophisticated screen with scroll menus as provided by
textmenu. Most choosers depends on the elilo config file to get the information they
display. The simple chooser can operated without the elilo config file. However it
is always better to have this file, to create handy logical names for each possible
boot choices. The logical names are specified with the "label" option in the config
file. They represent a specific kernel "image" and its specific options.
In elilo, the user can select a particular kernel image using the corresponding label
name. A simple example is as follows:
If we suppose that the following is defined in elilo.conf:
image=vmlinuz-2.4.9
label=linux-up
initrd=initrd-2.4.9
root=/dev/sda2
append="console=tty0 console=ttyS0,115200n8"
then the user can specify linux-up at the prompt and elilo will load the
vmlinuz-2.4.9 kernel file and the initrd-2.4.9 ramdisk and will pass
"root=/dev/sda2 console=tty0 console=ttyS0,115200n8"
as command line arguments to the kernel.
This behavior is identical to Lilo/x86. However, elilo further allows the user
to specify actual kernel files names as well, i.e., kernels that are not defined
in the configuration file. If we reuse the above example and the simple chooser,
the user can type:
ELILO boot: vmlinux-2.4.18 root=/dev/sda2
and elilo will boot the vmlinuz-2.4.18 kernel if it exists.
VI/ The alternate kernel image
--------------------------
Oftentimes when debugging kernels you want to reboot the machine once with
your test kernel and, if something goes wrong, you want to fall back to a more
stable kernel. In addition you want to be able to do this from a remote machine.
Many things can go wrong when doing kernel debugging. It could be that you don't
even reach user-mode. In this case however, you still want to fall back to
a stable kernel. The feature you'd like from a boot loader is 'boot once and
then fall back to safe kernel'.
Elilo offers this feature and it's called 'alternate kernel image'.
You can configure elilo to load a kernel only once and then whatever
happens the next reboot falls back to a different kernel hopefully more stable.
To do this, elilo relies on an EFI variable called 'EliloAlt' with a NULL GUID.
The content of this variable is a UNICODE string containing the kernel file name
and its command line options.
When the -a option is specified on the command line or if the "checkalt" option
is present in the config file, elilo will check for the presence of this variable.
If found and the content is a valid UNICODE string, elilo will use it as the kernel
to boot. There is no verification made on the validity of the kernel name or options.
Then the variable is deleted. If the variable is rejected because it does not look
sane, it is also deleted.
The variable can be set from a running Linux system using the /proc/efi/vars
interface. In the tools directory of this package, there is a Linux tool called
elilovar which can be used to create, modify, print, and delete the EliloAlt
variable. Refer to eliloalt.txt for more information on this tool.
VII/ Auto booting the machine
-----------------------
Once you're satisfied with your machine setup, it is good to install an
auto boot procedure. You have two options to do this:
- from the EFI boot manager menu
- from the EFI shell
The first option is preferred and is used by most Linux distributions.
Elilo can be invoked directly from the boot manager. You need to get into
the 'boot maintenance' menu and use load file a file. This can be tedious
so instead it is recommended that you use a Linux tool called efibootmgr
which is also shipped in most distributions. With this tool, you can
create your own boot option and change the boot order.
The second approach use the EFI shell and a shell script with a special name: 'startup.nsh'.
When the system boots, it looks for EFI partitions and if it finds
a 'startup.nsh' file in ANY of these it will jumpstart execution from it.
So the typical way of auto booting your Linux/ia64 system is to simply create
such a file with the following content:
# cat /boot/startup.nsh
elilo vmlinuz root=/dev/sda2
Of course, this can be simplified if there is a configuration file.
VII/ Netbooting
----------
Please refer to netbooting.txt for a complete description of how to boot
from the network.
XII/ Booting on EFI/ia32 platforms
-----------------------------
Until PC comes with the EFI firmware built in, you need to boot from a
floppy that has the EFI firmware on it. Such floppy can be
constructed from the EFI sample implementation and toolkit that is
available from the Intel Developer Web site at:
http://developer.intel.com/technology/efi/
To use elilo on IA-32, you can put it on a floppy and
on a FAT32 partition (msdos partition). You can also
netbooting if you network adapter has support for UNDI/PXE.
Elilo/ia32 is capable of booting unmodified 2.2.x. and 2.4.x kernels
as they are shipped by distributors today (such as Redhat7.2). You don't need
to recompile the kernel with special options. Elilo ONLY takes compressed kernel
image which are typically obtained via a 'make bzImage'. Plain elf/32 kernel can't
be booted (plain vmlinux will not work). Similarly, existing initial ramdisks can
be used without modifications.
IX/ Credits
-------
Intel Corp.
Stephane Eranian <eranian@hpl.hp.com>
David Mosberger <davidm@hpl.hp.com>
Johannes Erdfelt <jerdfelt@valinux.com>
Richard Hirst <rhirst@linuxcare.com>
Chris Ahna <christopher.j.ahna@intel.com>
Mike Johnston <michael.johnston@intel.com>
X/ Bug reports
-----------
You can submit bugs to <eranian@hpl.hp.com> or to the Linux/ia64
mailing list at linux-ia64@linuxia64.org. Visit http://www.linuxia64.org
to subscribe to this list.
XIII/ Reference
---------
EFI v1.02 specifications are available from the following web site:
http://developer.intel.com/technology/efi/
The latest sources of ELILO can be downloaded at:
ftp://ftp.hpl.hp.com/pub/linux-ia64

77
docs/eliloalt.txt Normal file
View file

@ -0,0 +1,77 @@
Information related to the eliloalt Linux tool
---------------------------------------------
(c) 2002-2003 Hewlett Packard Co
Contributed by Stephane Eranian <eranian@hpl.hp.com>
Last updated: March 1st, 2002
The elilo alternate image feature uses an EFI variable called EliloAlt.
The content of this variable is a UNICODE string containing a kernel
image file and its command line options. The variable has a NULL GUID.
To create, read, or modify the variable you need to use the EFI variable
service and the SetVariable() or GetVariable() interface. The service
is available when EFI is in boot service mode, i.e., prior to loading
the kernel but it is also available at runtime when the Linux kernel
has taken over the control of the machine.
In order to modify the variable, you can either write a small EFI applications
or use the Linux/ia64 interface to the EFI variables which use the /proc filesystem.
The elilalt tool included in this package uses the /proc interface to EFI variables
to create, read, or modify the EliloAlt variable. This tool is a Linux/ia64 application
and NOT an EFI application.
Because modiyfing the EliloAlt can influence how the machine is booted, you must
be root to run the program, even when you simply want to read the content of
the variable.
Eliloalt provides the following options:
-h, --help display this help and exit
--version output version information and exit
-s, --set cmdline set elilo alternate variable to cmdline
-p, --print print elilo alternate variable
-d, --delete print elilo alternate variable
1/ Creation of the variable
To create the variable you can type:
# eliloalt -s "vmlinuz-2.4.9 root=/dev/sdb2 hdc=ide-scsi"
It is VERY important to use quotes to make sure that the entire list of arguments is
treated as a single argument to the program. Otherwise only the first element
(here vmlinuz-2.4.9) will be used.
2/ Printing the content of the variable
To print the content of the variable you need to type:
# eliloalt -p
EliloAlt="vmlinuz-2.4.9 root=/dev/sdb2 hdc=ide-scsi"
3/ Modifying the variable
You can simply use the -s option:
# eliloalt -s "vmlinuz-2.4.18 root=/dev/sdb2"
# eliloalt -p
EliloAlt="vmlinuz-2.4.18 root=/dev/sdb2"
3/ Deleting the variable
You must use the -d option:
# eliloalt -p
EliloAlt="vmlinuz-2.4.18 root=/dev/sdb2"
# eliloalt -d
# eliloalt -p
variable not defined
Keep in mind that the variable is automatically deleted by elilo if:
- the checkalt option is specified in the config file
OR
- the -a is used on the command line

53
docs/elilovars.txt Normal file
View file

@ -0,0 +1,53 @@
Information related to variable support in ELILO
------------------------------------------------
(c) 2002-2003 Hewlett Packard Co
Contributed by Stephane Eranian <eranian@hpl.hp.com>
Last updated: 06/13/2002
As of version 3.2, elilo has internal variables which can be programmed
by any module inside the bootloader code. These variables are used
to parametrize some of the arguments passed on the kernel command line.
The value of a variable is a Unicode string. Variables names are composed
of a single Unicode character, such as 'I' for instance. Variable names
are case sensitive. Elilo has support for 52 variables: A-Z and a-z.
The '%' sign is used to name a variable. For instance, '%I' indicates
variable 'I'. If '%I' is present on the command line to the kernel,
it will be replaced (string replacement) with the value (a string) of 'I'.
By default, the Elilo core does not assign any values to any variables.
It is up to each module to do so. When a variable is not used, its content
is the empty string "", which means that the '%d' notation, for instance, will
be replaced with the empty string.
Let us look at an example:
Supposing that the following variables are defined:
'I' -> "192.168.2.5"
'G' -> "192.168.2.1"
'M' -> "255.255.255.0"
'z' -> ""
Then a command line of this form (provided as an append= option in elilo.conf):
root=/dev/nfs nfsroot=15.4.88.178:/mnt2 ip=%I:%z:%G:%N:jung:eth0:on
Would pass the following to the kernel:
root=/dev/nfs nfsroot=15.4.88.178:/mnt2 ip=192.168.2.5::192.168.2.1:255.255.255.0:jung:eth0:on
Of course, the meaning of each variable is up to each individual module, the
names used here are not necessarily representative of the actual names used
by elilo.
Some choosers, (such as simple) have support to print the list of
defined variables. For instance, in simple (the default chooser) you
can press '%' to see the list of defined variables.
Variables can be useful when netbooting, for instance, to get the
dynamically assigned IP, netmask, and gateway addresses.
In case the % character needs to be passed to the kernel, it is possible
to "despecialize" a character using the & symbol in front of it.
See netbooting.txt for more information on this.

22
docs/fpswa.txt Normal file
View file

@ -0,0 +1,22 @@
Information related to the FPSWA driver for EFI/ia64 platforms
--------------------------------------------------------------
(c) 2002-2003 Hewlett Packard Co
Contributed by Stephane Eranian <eranian@hpl.hp.com>
This document is irrelevant for EFI/ia32 platforms.
On all EFI/ia64 platforms, the bootloader is responsible for checking for
the presence on the EFI system partition of an updated version of the
Floating-Point Software Assist (FPSWA) EFI driver (fpswa.efi). For every
instance found, elilo will load the driver and let EFI decide if it is
newer than the currently installed version. In the end at most one driver
is kept in memory.
Elilo will look for a file called fpswa.efi in the \EFI\Intel Firmware
(there is a space between l and F) directory on ALL accessible EFI system
partitions (including on removable media). It will do so even when elilo
is downloaded from the network. It does not look for the driver in the
ext2fs partitions.
The FPSWA reference document is available from the Intel developer's web
site at http://developer.intel.com/design/itanium.

396
docs/netbooting.txt Normal file
View file

@ -0,0 +1,396 @@
How to netboot using ELILO
--------------------------
Copyright (C) 2002-2003 Hewlett-Packard Co.
Contributed by Stephane Eranian <eranian@hpl.hp.com>
Last updated: 03/08/11
EFI has full support for the PXE and DHCP protocol. As such
it is relatively easy to boot a machine from the network using EFI.
The elilo loader has full support for both PXE and DHCP, therefore
it is possible to download the elilo config file, the Linux kernel image
and the initial ramdisk from a remote server. There are many ways
netbooting can be configured but in this document we focus
only on two very common cases:
- netboot but use local root filesystem.
- booting a diskless machine, i.e., use a NFS root filesystem.
1/ How to get EFI to netboot?
You do not need any additional software to get EFI to start a netboot session.
Any EFI machine can be configured to start a PXE/DHCP session IF it has a network
adapter that has support for the UNDI/PXE protocol. Most modern cards do have such
support.
To enable netbooting, you need to go into the EFI boot manager maintenance menu
and 'Add a boot option'. On the screen you see the list of devices to boot from.
At least one of them should be of the form:
Load File [Acpi(PNP0A03,0)/Pci(5|0)/Mac(00D0B7A6FC25)]
which represent Ethernet card (Mac address). If you don't have such option, it means that
you either do not have a network adapter in your machine or it does not have the
UNDI/PXE support in its option ROM.
You need to select this option and give it a logical name such as 'netboot', for instance.
Next, you leave the maintenance menu and go back to the main menu. You now have a new
boot menu option. If you select 'netboot' then EFI will start the PXE/DCHP discovery
request and look for a server to get an IP address.
On the server side, you can use a standard DHCP server, such as the one shipped on
Redhat7.2 (dhcpd) or a PXE server (not yet available for Linux, probably available for Windows).
In this document we show both options. You also need a TFTP server somewhere on the network,
it will be used to download the actual files.
2/ Netbooting using DHCP
There is nothing specific to EFI that needs to be set in the /etc/dhcpd.conf file.
Clearly the filename option must contains the path to the elilo.efi binary.
Elilo will auto-detect whether it was downloaded via PXE or DHCP and it will adapt
the kind of requests it makes to download the other files that it needs, such as
its config file.
A simple dhcpd.conf file which uses fixed IP addresses could be as follows:
subnet 192.168.2.0 netmask 255.255.255.0 {
host test_machine {
hardware ethernet 00:D0:B7:A6:FC:25;
fixed-address 192.168.2.10;
filename "elilo.efi";
option domain-name "mydomain.com";
option host-name "test_machine";
option routers 192.168.2.1;
option subnet-mask 255.255.255.0;
}
}
For the tftp server, you need to make sure that it is ACTIVATED by inetd or xinetd depending
on your distribution. In most distributions, it is disabled by default for security reasons.
On distributions using xinetd, you need to check /etc/xinet.d/tftp. For inetd you need to
check /etc/inetd.conf. It is typical to have the root directory for tftp be /tftpboot but it
can be anything. In this document we will use /tftpboot as the root directory. The files
that we need are as follows:
- elilo.efi
- the elilo config file
- the kernel image
- the initial ramdisk (optional)
a/ Location of the files in the tftp directory tree
For elilo version 3.3b or higher, it is possible to place the files listed above
in any subdirectory below the tftp root. Of course the dhcpd.conf file must
point to the location of elilo.efi and provide the path from the tftp root
directory.
Elilo will look for its config file, the kernel image, the initial ramdisk (optional)
only from the directory it was loaded from. This is useful when the same tftp server
is used to services many different kind of clients.
Here is a simple example, suppose the dhcpd.conf file contains the following definition:
subnet 192.168.2.0 netmask 255.255.255.0 {
host test_machine {
hardware ethernet 00:D0:B7:A6:FC:25;
fixed-address 192.168.2.10;
filename "/rx6000/elilo.efi";
option domain-name "mydomain.com";
option host-name "test_machine";
option routers 192.168.2.1;
option subnet-mask 255.255.255.0;
}
}
Elilo will be downloaded from /tftpboot/rx6000. Then elilo will look
for all the other files it needs in /tftpboot/rx6000. This rule is
applied to all files, including the all the variation of the config
file.
b/ Getting the config file
With DHCP, elilo will first try to download its configuration file. It will try
several file names and they are as follows:
1) AABBCCDD.conf
where AABBCCDD is the hexadecimal representation of the IP address assigned to
the machine by DHCP. The hexadecimal string (AABBCCDD) MUST use upper case
characters.
This filename is an opportunity to specify a machine specific configuration file.
2) elilo-ia32.config or elilo-ia64.conf
Depending on the machine (client side) architecture elilo will try the IA-32 or
IA-64 file.
This filename is an opportunity to specify a architecture specific configuration file.
This distinction between the architectures is useful when the same TFTP server services
the two types of clients : IA32- and IA-64 machines.
3) elilo.conf
All files use the same format. Elilo will stop at the first match. In case no file is found,
it will try to download a default kernel file name (vmlinux).
c/ Getting the kernel
The second request from elilo is typically the kernel image. The filename is based on what
is in the elilo config file. The path name depends on how the TFTP server is configured.
For security reasons it is customary to have the server do a change root in /tftpboot.
Hence filenames are relative to /tftpboot and therefore you don't need to specify it.
For instance if elilo.conf contains:
image=vmlinuz.249
label=linux-up
root=/dev/sdb2
and the user selects linux-up, then elilo will request a filename of 'vmlinux.249'
which must therefore be in /tftpboot. Check the configuration of your TFTP server for
more on this.
d/ Getting the initial ramdisk
This step is optional. It follows exactly the same naming rules explained for the kernel image.
The initial ramdisk file must therefore be somewhere under /tftpboot.
For instance if elilo.conf contains:
image=vmlinuz.249
label=linux-up
root=/dev/sdb2
initrd=ramdisk/initrd.249
and the user selects linux-up, then elilo will request a filename of 'ramdisk/initrd.249'
which must therefore be under /tftpboot.
e/ Getting IP address information
When elilo is netbooted, the network filesystem module initializes some elilo variables
with the information it received from the DHCP server. At a minimum, it received the
IP address.
The following information is stored in the elilo variables indicated below:
- assigned IP address -> %I
- assigned netmask -> %M
- assigned domainname -> %D
- assigned gateway -> %G
These variables can be used to dynamically adjust the command line arguments passed to the kernel.
See section 5/ below for an example.
3/ Netbooting using PXE
EFI has builtin support for PXE. In fact it first tries PXE and then default to DHCP
when it does not find a valid PXE server.
There is a PXE server package available from Linux/ia32 however this package does not
have the necessary extensions to talk to the EFI side, at least on IA-64 platforms.
There is no need for special options or compile time flags to get elilo to work
with PXE instead of standard DHCP. When netbooted, elilo will automatically detect
if it has been downloaded via PXE or DHCP and it will adujst how subsequent files
are requested.
You need a special version of the DHCPD server developed by the Internet Software Consortium
(http://www.isc.org) with a special patch to add the PXE extensions. Unfortunately as of
version 3.0xx, the patch has not yet made it into the official tree. It is supposed to show
up in version 3.1 of the dhcpd server.
In any case, the elilo package contains a simple example of how you can configure the
/etc/dhcpd.conf file for a PXE-aware DHCP server using the extensions provided in the
patch. You can look in examples/dhcpd-pxe.conf. The syntax is very different from
a standard dhcpd server.
The key elements to keep in mind are the PXE layers used by elilo to request the different
files:
Layer 0 : to get the name of the boot loader (elilo.efi)
Layer 1 : to get the name of the elilo config file
Layer 2 : to get the name of the kernel image
There is an IMPORTANT distinction between those layers. The first two (0,1) and requested
systematically whereas the last one is used only when the configuration file is not found, i.e.,
what is the default kernel to boot. The actual files are STILL downloaded via TFTP. Therefore
the TFTP server must also be configured (see previous section for more on this).
a/ Getting the config file
In this mode, elilo use the PXE layer 1 to get the config file to use. Therefore this must
be set on the server side. Elilo will use the following sequence when
looking for a config file:
- use the name provide by the PXE server Layer 1 or
- elilo-ia64.conf/elilo-ia32.conf or
- elilo.conf
Elilo stops at the first match. With PXE, elilo does not try to download a config file named after
the assigned IP address as it does for DHCP because there is enough flexibility in the PXE server
configuration to do this.
b/ Getting the kernel image
When there is no config file, elilo will use the kernel name returned by
PXE layer 2. If it is not specified there, then it default to 'vmlinux'.
c/ Getting the initial ramdisk
The filename for the ramdisk MUST come from the config file. Elilo does not use a PXE layer
to ask for a default name.
d/ Getting IP address information
When elilo is netbooted, the network filesystem module initializes some elilo variables
with the information it received from the DHCP server. At a minimum, it received the
IP address.
The following information is stored in the variables indicated below:
- assigned IP address -> %I
- assigned netmask -> %M
- assigned domainname -> %D
- assigned gateway -> %G
These variables can be used to dynamically adjust the command line arguments passed to the kernel.
See section 5/ below for an example of how to use the variable.
4/ Netbooting and using a local root filesystem
This is the simplest configuration where the boot loader, its config file, the kernel
and its optional initial ramdisk are downloaded from the network BUT the kernel uses
the local disk for its root filesystem.
For such configuration there is no special option necessary in the elilo config file.
You simply need to specify which partition is the root partition. A typical elilo.conf
would look as follows:
image=vmlinuz.249
label=linux-up
root=/dev/sdb2
initrd=ramdisk/initrd.249
5/ Netbooting a diskless machine
In this configuration we do not use the local machine's disks but instead rely on
a remote server to provide the root filesystem via NFS.
a/ Prerequisites
By default most kernels shipped by distributors do not have the support
compiled in for such configuration. This means that you need to recompile
your own kernel. For instance, vmlinuz-2.4.9 as shipped in Redhat7.2 on
both ia32 and ia64 platforms does not have the support builtin.
To get this configuration to work, you need to have a kernel compiled
such that it accepts a root filesystem over NFS (CONFIG_ROOT_NFS). This
necessitates that the network stack be configured with the, so called,
IP plug-and-play support (CONFIG_IP_PNP).
b/ On the server side
You need to have:
- a NFS file server to provide the root filesystem.
- a DHCP/PXE server to get the IP address and download the boot loader.
Note that both do not need to be on the same machine. There is no special
DHCP/PXE configuration option required to get this working. All you need
is a kernel compiled with the options mentioned in a/. You also need to
make sure that the permission on the NFS server are set appropriately
to allow root access from the client machine (no_root_squash), see
man 'exports' for more on this.
c/ The elilo configuration file
To boot successfully, the kernel needs to:
- get an IP address and related networking parameters
- contact the NFS server to get its root filesystem
The 2.4.x kernel series provides several options to get the IP address:
- it can do an internal DHCP request (CONFIG_IP_PNP_DHCP)
- it can do an internal RARP request (CONFIG_IP_PNP_RARP)
- it can do an internal BOOTP request (CONFIG_IP_PNP_BOOTP)
- it can get the IP address from the command line
The choice is up to you but it is a little bit stupid to go through a
DHCP/BOOTP/RARP phase again when this is already done by the EFI firmware.
So in this document, we describe how you can pass the information provided
by EFI on the command line of the kernel.
The syntax used to pass IP information on the command line is described in
the kernel source tree in Documentation/nfsroot.txt. The option is called
"ip=" and has the following syntax:
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
To designate the NFS server, you must use the "nfsroot=" option. It has the
following syntax:
nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
Depending on how you want your system configured you can hardcode the
values of the parameters in the elilo configuration file. For instance:
image=/vmlinuz
label=nfsroot
description="kernel with NFS root"
append="root=/dev/nfs nfsroot=192.168.2.22:/ia64_rootfs ip=192.168.2.5::192.168.2.1:255.255.255.0:test_machine:eth0:on"
Note the root=/dev/nfs indicates that the root filesystem is over NFS.
This example works fine however, it is not very flexible because the IP
address, the gateway, netmask and hostname are fixed and do not used the
values EFI used to download the boot loader and the kernel.
Elilo provides a way to dynamically customize the parameters passed on the
command line using substitution variables. We describe those variables in
elilovar.txt. The basic idea is to allow the parameters to use the dynamic
information obtained by the DHCP/PXE phase.
The network support in elilo defines several variables which contained
network related information produced by the DHCP/PXE phase. The set of
variable is:
%I -> the IP address obtained by DHCP/PXE
%M -> the netmask obtained by DHCP/PXE
%G -> the gateway obtained by DHCP/PXE
%H -> the hostname obtained by DHCP/PXE
%D -> the domain name obtained by DHCP/PXE
So, the configuration file can then be customized as follows:
image=/vmlinuz
label=nfsroot
description="kernel with NFS root"
append="root=/dev/nfs nfsroot=192.168.2.22:/ia64_rootfs ip=%I::%G:%M:%H:eth0:on"
Not all parameters are necessary or even used by the kernel or the user level
configuration scripts. There is no variable to substitute the NFS server or
the mount point on that server.
In the case of a DHCP boot, this type of customization makes sense only for
the shared configuration file, elilo-ia64.conf/elilo-ia32.conf or elilo.conf.
The configuration file based on the IP address (such as C0A80205.conf in this
case) would provide another way of customizing parameters for a specific
client (IP address). The same thing holds if the name of the config file
returned by the PXE server is specific to a client.
6/ References
More information on the PXE protocol can be found at the following web site:
http://developer.intel.com/ial/wfm/
The source code for the standard and (possibly) PXE-enhanced DHCPD can be
downloaded from:
http://www.isc.org/

156
docs/simple_chooser.txt Normal file
View file

@ -0,0 +1,156 @@
Information about the simple chooser
--------------------------------------
Copyright (C) 2002-2003 Hewlett-Packard Co.
Contributed by Stephane Eranian <eranian@hpl.hp.com>
Last updated: 02/02/14
Chooser name: simple
Command line option: -C simple
Config file option: chooser=simple, description, message
The simple chooser is the default chooser. However it is possible
to disable it at compile time, it is highly recommended to keep it
in. Elilo must have at least one chooser compiled in.
The simple chooser is very basic as its name indicates! It provides
a simple one line text mode command prompt similar to what you get
with Lilo/x86.
Any chooser becomes visible to the user ONLY when the interactive
mode is entered.
The simple chooser allows the user to select a kernel to boot.
The user can use a label as specified in the elilo config file
or a kernel file name. File names can be specified with
absolute names in the form dev_name:/path/to/my_kernel.
1/ Activation
The chooser is activated from:
- command line with the -c simple
- the config file with the chooser=simple option
2/ Supported options
The simple chooser supports the following options in the config file:
message=filename : display a message before the prompt. The filename
must be an ASCII file
description=string: a description of the kernel image (ASCII)
All other options have their standard meaning. The chooser does not recognize
the fX (X varies from 1-12) options
2/ Builtin commands
The simple chooser has some builtin command which the user can
get to by typing certain keys as the first character on the command line:
TAB: shows the list of defined labels and their descriptions.
If the user did not type anything, i.e., the line is empty,
pressing TAB will print the list of labels defined in the
elilo config file.
If the user already typed a name and if the name corresponds
to a specified label, the chooser will show how the label
is expanded and what the final command line to the kernel will
look like.
If the line is empty pressing TAB generates something similar to:
ELILO boot:
linux-up linux nfsroot (or any kernel file name: [dev_name:]/path/file)
Note that first label correspond to the default label used if the user
hits the enter key with an empty line. This label is not necessarily
the first one in the config file.
Now pressing TAB with a full label name:
ELILO boot: linux-up
desc : my default UP kernel
cmdline: vmlinuz root=/dev/sdb2 console=ttyS0,115200n8 console=tty0 ro
The desc line shows whatever was specified in the "description" option
for this particular image in the config file.
= : shows the list of accessible devices
this key force elilo to print the list of detected devices. Elilo will
auto-detect the devices which are accessible to load a config file, the kernel, the
initrd from. Those devices typically represent disk partition, CDROM, floppy, or
a network path. The list of devices is highly system dependent.
It also depends on the filesystem support compiled into elilo.
The way the devices are named depends on the device naming scheme
selected. It also depends on whether the EDD30 support is activated.
For instance, pressing the ? could look as follows:
ELILO boot:
scsi0 : vfat : Acpi(PNP0A03,2)/Pci(1|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig72040800)
scsi1 : vfat : Acpi(PNP0A03,2)/Pci(1|0)/Scsi(Pun6,Lun0)/HD(Part1,Sig00000000)
scsi2 : ext2fs : Acpi(PNP0A03,2)/Pci(1|0)/Scsi(Pun0,Lun0)/HD(Part2,Sig72040800)
scsi3 : ext2fs : Acpi(PNP0A03,2)/Pci(1|0)/Scsi(Pun6,Lun0)/HD(Part2,Sig00000000)
net0 : netfs : Acpi(PNP0A03,0)/Pci(5|0)/Mac(00D0B7A6FC25)
5 devices available for booting
boot device net0: netfs
Here the vfat (EFI partition type), ext2fs and network filesysten (not to be confused
with NFS) were compiled into elilo and were detected on the machine. The left handside
of the colon show the logical name associated with the device. For instance,
scsi0 corresponds to the first partition of SCSI disk ID 0 and is an EFI partition.
The net0 correspond to a network device, here the Ethernet adapter. The last line
show the device used to load elilo itself, in the case elilo was downloaded from the
network.
To get a kernel from scsi0, the user can simply type:
ELILO boot: scsi0:/usr/src/linux/vmlinux
Note that even though elilo was not downloaded from the network, it is still possible
to get the kernel and initrd from a remote machine.
% : shows the list of defined variables
Elilo has builtin variables which are used to dynamically customized the command line
parameters passed to the kernel. The list of variables depends on the support compiled
into elilo. Not all elilo subsystems use variables. Typically the network file system
does. Pressing '%' only prints the variables that are defined with their current values.
Some variables are only defined once the subsystem that creates them has been used.
In other words, if the network filesystem was not used to load elilo, then the variables
defined by it are not created.
If the network was actually used, pressing '%' could generate the following output:
ELILO boot:
D = "mydomain.com
G = "192.168.3.1"
H = "test_machine"
I = "192.168.3.4"
M = "255.255.255.0"
& : shows the list default path
The path is used as a prefix for all filenames specified as
relative.
? : shows the list of supported command keys
The simple chooser has also some builtin command line editing commands:
ESC : abort (leave elilo)
CTRL-D : abort (leave elilo)
CTRL-C : kill line
empty current line and prompt for new input
CTRL-H : erase the previous character
CTRL-U : clear current line
reset the buffer (does not display correctly if buffer spans more than one line)
Backspace: erase character

61
docs/textmenu_chooser.txt Normal file
View file

@ -0,0 +1,61 @@
Information about the textmenu chooser
--------------------------------------
Copyright (C) 2002-2003 Hewlett-Packard Co.
Contributed by <rhirst@linuxcare.com>
Last updated: 02/02/14
Chooser name: textmenu
Command line option: -C textmenu
Config file option: chooser=textmenu
The textmenu chooser provides a facility whereby you can draw a colour
boot screen, using line-drawing characters to give the impression of a
dialog box, with a scrollable menu from which a boot image can be chosen
via cursor up/down keys. A one-line input field is provided for additional
parameter input. Menu entries are taken from the description= fields in
the config file.
The message file format is based on that used for syslinux/isolinux on ia32
platforms, which is copyright H. Peter Anvin. It is basically a text file
containing text and graphic characters, along with some control codes to
specify colour attributes, menu, and prompt field positions. There are two
classes of message files; the main file, specified via message=, which
includes menu and prompt field markers, and the additional help files which
are invoked via function keys. Graphic characters are taken from the
standard IBM VGA character set, and using an appropriate font makes file
creation easier. Under Linux you can find a VGA font in the dosemu package.
Included in the elilo source is sys2ansi.pl (taken from syslinux), which can
be used to translate colour attributes such that they display correctly in an
xterm.
Valid control codes:
0x01 ^A Mark top left or bottom right of menu area. Current attributes
at top left marker are used for inactive menu entries, current
attributes when bottom right marker is found are used for the
currently active menu attributes.
0x02 ^B Mark left- or right-hand end of the prompt field. Current attributes
at the left had end are used to display and parameters entered.
0x0A ^J Linefeed, does implied carriage return.
0x0C ^L Clear screen
0x0D ^M Carriage return; ignored so files can be 'DOS' or 'UNIX' format.
0x0F ^O Attribute specfication; Two hex digits should follow this code, the
first being the background colour required, the second the foreground.
0 = black 8 = dark grey
1 = dark blue 9 = bright blue
2 = dark green a = bright green
3 = dark cyan b = bright cyan
4 = dark red c = bright red
5 = dark purple d = bright purple
6 = brown e = yellow
7 = light grey f = white
An example of a config file and message file are included in the examples
directory.