Alternate Bootloaders (202.3)
Alternate Bootloaders (202.3)¶
Candidates should be aware of other bootloaders and their major features.
Key Knowledge Areas¶
SYSLINUX, ISOLINUX, PXELINUX
Understanding of PXE for both BIOS and UEFI
Awareness of systemd-boot and U-Boot
Booting UEFI systems
Terms and Utilities¶
The lilo bootloader consists of two stages. During the two stage boot, LILO indicates its progress by printing consecutive letters from the word \"LILO\" to the BIOS console, with one letter at the start and end of each stage.
Errors during either stage result in only parts of the word being
printed, optionally followed by a numeric BIOS error code, or a single
In interactive mode (
prompt keyword in
/etc/lilo.conf) LILO presents
the user with a choice of up to 16 entries. If no
in tens of a second) is specified, the bootloader will wait
indefinitely. If the timeout expires, or no
prompt was included, LILO
proceeds by loading the first image listed. This can be overruled with
/etc/lilo.conf and /sbin/lilo¶
Unless modern bootloaders, neither stage of LILO is actually aware of
the contents of
/etc/lilo.conf. Instead, the file is used only as a
specification for the lilo installer, typically at
/sbin/lilo will install the bootloader into the
MBR, and process the contents of
/etc/lilo.conf, creating a mapping of
any files specified to store into
Please refer to the
lilo.conf(5) man page online for a detailed
/etc/lilo.conf (from an older debian distribution)
# lilo.conf # # global options: boot=/dev/hda prompt timeout=150 lba32 compact vga=normal root=/dev/hda1 read-only menu-title=" John's Computer " # # bootable kernel images: image=/boot/zImage-1.5.99 label=try image=/boot/zImage-1.0.9 label=1.0.9 image=/tamu/vmlinuz label=tamu initrd=initramdisk.img root=/dev/hdb2 vga=ask # # other operating systems: other=/dev/hda3 label=dos boot-as=0x80 # must be C: other=/dev/hdb1 label=Win98 boot-as=0x80 # must be C: other=/dev/hdb5 label=os2 loader=os2_d table=E: # os2 sees as E:
SYSLINUX, ISOLINUX, PXELINUX: The Syslinux Project¶
SYSLINUX is a linux bootloader designed to run from an MS-DOS/Windows
FAT file system. It is limited to Intel/AMD hardware.
Over time, the Syslinux project (http://syslinux.org) expanded to
include support for booting natively from CD-ROMS (
file systems (
EXTLINUX) and over PXE (
This summary handles the LPIC-2 specific objectives. A full description can be found in the syslinux wiki at http://www.syslinux.org/wiki/index.php/SYSLINUX
SYSLINUX is an Intel Linux bootloader which is able to boot from Windows/MS-DOS FAT based file systems. It can be installed with the command of the same name, from either Windows, MS-DOS, or linux.
The syslinux system consists of the actual bootloader and its installer. The bootloader itself is a 32bit native binary written in assembler.
syslinux installer command comes in different versions:
syslinux.exe for Windows,
syslinux for linux. There is even a
syslinux.com for DOS based systems.
SYSLINUX Installer Options¶
1 2 3 4 5 6 7 8 9 10 11 12 13
MSDOS specific options¶
Exceptions for ISOLINUX, EXTLINUX, PXELINUX¶
The ISOLINUX Installer¶
syslinux expects a target device to write the bootloader, the
isolinux installer generates an ISO image from a directory structure.
The directory must include a subdirectory
isolinux which in turn must
include the actual
The EXTLINUX Installer¶
extlinux installer expects a mounted file system to install the
is treated in PXELINUX.
Syslinux Boot Configuration¶
The bootloaders installed by these utilities will look for a
syslinux.cfg file in the following three directories:
The ISOLINUX bootloader will first look for
/isolinux. The EXTLINUX bootloader looks for
The directory where the config file is found will be the default directory for further pathnames in the boot process.
The CONFIG keyword will restart the boot process with a new config file. If two pathnames are supplied, the second parameter overrides the default directory.
The boot process will look in the
syslinux.cfg file for a line with
\"LABEL linux\". When found, it will use any subsequent keywords to
guide the boot process. (A
DEFAULT label phrase can be used to
override the \"linux\" label.)
Typical keywords in a boot configuration:
KERNELkeyword specifies an image file. This does not have to be an actual kernel image, but can be the name of the next stage bootprogram. SYSLINUX e.a. rely on filename extensions to decide on the file format.
: is used with PXELINUX for the PXE NBP (Network Boot Program), with
pxelinux.0being the default.
: used with ISOLINUX, and refers to the CD Boot Sector,
: refer to (patched) DOS bootsectors [SYSLINUX].
: are COMBOOT images (DOS,non-DOS,32 bit). For versions 5.00 and later
c32changed from COMBOOT to ELF binary format.
: is an ISOLINUX diskimage.
Any other file extension (or none at all) indicate a linux kernel image.
The file type can also be forced by using one of the
APPENDkeyword specifies a string of boot parameters that is appended to the kernel command line. Only the last
APPENDline will be applied.
SYSAPPENDkeyword expects a numeric argument that is interpreted as a bitmap. Each bit in this bitmap will add a specific auto-generated string to the kernel command line.
1:Adds a string with network information:
BOOTIF=..., identifying the active network interface by its mac address.
4:Adds the string
Higher order bits (0x00010 through 0x10000) control additional strings from DMI/SMBIOS, if available. A full list can be found in the Syslinux wiki: http://www.syslinux.org/wiki/index.php/SYSLINUX\"
INITRDkeyword is equivalent to
- For interactive use, the argument to
TIMEOUTindicates the number of tens of a second that SYSLINUX should wait for input on the console or serial port.
The PXELINUX bootloader is used as the second stage of a PXE network boot. The PXE network boot mechanism is further explained in Understanding PXE.
PXELINUX expects a standard TFTP server with a
pxelinux.0 syslinux bootloader, and the
In addition, a directory
/tftpboot/pxelinux.cfg must exist for
additional configuration details.
A PXE TFTP boot server can serve many different clients, and needs a way to maintain different configuration files for different (categories of) clients. There are many different ways in which the name of the configuration file can be specified.
Combine DHCP Option 209 and 210¶
Option 209 (
pxelinux.config-file) specifies the filename for the configfile.
Option 210 (
pxelinux.pathprefix) specifies the search path (directory prefix) on the TFTP server namespace (ending in the OS-specific separator character for the file system).
Hardcoded in the
pxelinux-optionscommand can be used to hardcode the options as shown in this table
number option 6 domain-name-servers 15 domain-name 54 next-server 209 config-file 210 path-prefix 211 reboottime
Options can be specified as 'before-options', where DHCP has precedence, or as 'after-options', which override DHCP.
Derived from UUID, MAC-address, or IP-Address¶
If no config file is specified, the filename is derived from a list of variables. The first file in the list that actually exists on the TFTP server will be used.
The list of variables is:
The client's UUID, in lower case.
The client's MAC address, in lower case hexadecimal, with bytes separated by a dash (\"-\").
The longest possible prefix of the Upper case hexadecimal representation of the client's ipv4 address. Each time the string does not match, PXELINUX drops the last character from the string and tries again as long as the result contains at least one character.
As a last resort, PXELINUX will try to retrieve the file named \"default\".
PXE is a specification created by Intel to enhance the original network boot protocols: BOOTP, TFTP and DHCP.
BOOTP, RARP and TFTP were created by the IETF to enable systems to automatically retrieve their network configuration and initial bootloader from a server.
The initial BOOTP standard was limited to a number of fixed fields in
which client and server could exchange information. A client could
supply its hardware address in
chaddr, and request a specific type of
file, and would receive its ip address as
yiaddr and a servername
sname. Combined with the server IP address field (
siaddr) and the
gateway IP address field, and the returned boot file name (
would tell the boot client where to retrieve its boot image, using TFTP.
1 2 3 4 5 6 7 8 9
Over time networks and IT infrastructure became more complicated and requirements more demanding. To allow clients to provide more information about themselves and to retrieve tailored information, BOOTP received the BOOTP Vendor Information Extensions [RFC 1048], which in turn was enhanced with a new protocol, DHCP. DHCP extended BOOTP with a number of standard options, defining different types of messages. Some DHCP options may overlap with standard BOOTP fields, and should contain the same value in that case.
A DHCP message is a BOOTP packet (request or response) with a special 4
byte value (the DHCP magic cookie) in the BOOTP \"Vendor Information
Field\". Following that are DHCP options, consisting of a single byte
option type, a length field, and
length bytes of option content.
This rule has two exceptions: Padding (
0) and End of Options
255) are just one byte in length and lack a length field.
Finally, Intel introduced PXE, to enhance the BOOTP/DHCP protocol even further, in an attempt to standardise the way clients can identify themselves. This allows boot clients and servers to minimize the number of packets that needs to be exchanged before they can decide on the correct parameters and the boot program needed to get going.
A PXE boot request starts with a DHCP Discover message including at least five options, of which three are PXE-specific:
1 2 3 4 5
Options 93, 94, and 97 are defined in the PXE specification. In addition, option 55, the Parameter Request List, must *also* request options 128 through 135, even though a server is not required to provide a response to them. This list and the three options listed above act to identify the client as PXE aware.
Proxy DHCP for PXE¶
Not every DHCP server (especially those embedded in network equipment) will be able to process a PXE request.
The PXE specification allows PXE-aware DHCP servers to co-exist with simple DHCP servers, where the default DHCP server provides the basic network detail. The PXE-aware server can then provide additional detail for the actual TFTP boot process. This is called proxy-DHCP.
It is even possible to separate DHCP services on the same server, in which the proxy DHCP service is expected to listen to UDP port 4011.
Example DHCP request¶
See below for an example DHCP Discover message, including requests for standard network detail such as (1) Subnet Mask, (3) Router, (6) Name server, (12) Host Name, (15) Domain Name, etc.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59
Systems with UEFI¶
UEFI is a protocol known as Unified Extensible Firmware Interface (UEFI) Secure Boot. This was to be a modern replacement for the aging BIOS system and would help ensure boot-time malware couldn't be injected into a system.
The BIOS replacement, UEFI, requires a digital key installed for the OS to pass the UEFI firmware check to be able to boot. Mainstream Linux distributions like Red Hat, Ubuntu and Suse for example have purchased those keys so they have no problems with Secure Boot systems.
Without this digital key you generally still should be able to use Linux on a secure boot system. You can start with disabling the folowing in your BIOS:
1 2 3 4 5
If you get a Secure boot or signature error, you need to disable Secure Boot. If your system is running Windows 7, you can enter the BIOS by entering the keyboard key required to enter the BIOS settings and disable Secure Boot. If the system comes with Windows 8 you will need to boot into Windows and choose to do an Advanced startup. This should allow you to enter the BIOS and disable Secure Boot. Not: Sometimes a BIOS is able to run in EFI or legacy mode. If your system allows this you should not have any problems installing Linux
Booting with Systemd-boot¶
Systemd comes with Systemd-boot. This is intended for use with EFI
systems. It can only start EFI executables such as the Linux kernel
EFISTUB, UEFI Shell, GRUB and the Windows Boot Manager. Systemd-boot is
managed with the
bootctl command. systemd-boot requires an EFI System
Partition (ESP), preferably mounted on
/boot. The ESP must contain the
EFI binaries. Further information and examples can be found at
Booting with Das U-boot¶
Das U-boot "the Universal Boot Loader" is an open source, primary boot loader aimed at embedded devices. It is used to package the instructions to boot the kernel code. It is supporting many computer architectures, including 68k, ARM, AVR32, Blackfin, MicroBlaze, MIPS, Nios, SuperH, PPC and x86. U-Boot can be split into stages if there are size restraints. U-Boot requires explicit commands as to where the memory addresses are to copy the kernel, ramdisk, etc data to opposed to other bootloaders which automatically choose the memory locations. Due to the U-Boot commands being low-level, booting a kernel requires multiple steps. This allows U-Boot to be very flexible. U-Boot can boot from on board storage, the network and even serial ports.