Candidates should be able to properly manipulate a Linux system during both the boot process and during recovery mode. This objective includes using both the init utility and init-related kernel options. Candidates should be able to determine the cause of errors in loading and usage of bootloaders. GRUB version 2 and GRUB Legacy are the bootloaders of interest.

$ Resources: archNVMe,$ LPIC2sybex2nd; wikiUEFI; archUEFI; tomsUEFI; UEFI; LUtHL; Aplus901902;

GRUB (short for GRand Unified Bootloader) loads the operating system kernel and transfers execution control to it.

Two major versions of GRUB exist. The current version is known as GRUB but is in fact GRUB 2. GRUB has been developed around 2011. The older version was developed back in 1999 and is now referred to as GRUB Legacy. GRUB Legacy is still in use but its development has been frozen. Unless specified otherwise, GRUB implies GRUB 2 from here on.

	o acpi:                 Load ACPI tables
	o badram:               Filter out bad regions of RAM
	o blocklist:            Print a block list
	o boot:                 Start up your operating system
	o cat:                  Show the contents of a file
	o chainloader:          Chain-load another boot loader
	o cmp:                  Compare two files
	o configfile:           Load a configuration file
	o cpuid:                Check for CPU features
	o crc:                  Calculate CRC32 checksums
	o date:                 Display or set current date and time
	o drivemap:             Map a drive to another
	o echo:                 Display a line of text
	o export:               Export an environment variable
	o false:                Do nothing, unsuccessfully
	o gettext:              Translate a string
	o gptsync:              Fill an MBR based on GPT entries
	o halt:                 Shut down your computer
	o help:                 Show help messages
	o initrd:               Load a Linux initrd
	o initrd16:             Load a Linux initrd (16-bit mode)
	o insmod:               Insert a module
	o keystatus:            Check key modifier status
	o linux:                Load a Linux kernel
	o linux16:              Load a Linux kernel (16-bit mode)
	o list_env:             List variables in environment block
	o load_env:             Load variables from environment block
	o loopback:             Make a device from a filesystem image
	o ls:                   List devices or files
	o normal:               Enter normal mode
	o normal_exit:          Exit from normal mode
	o parttool:             Modify partition table entries
	o password:             Set a clear-text password
	o password_pbkdf2:      Set a hashed password
	o play:                 Play a tune
	o pxe_unload:           Unload the PXE environment
	o read:                 Read user input
	o reboot:               Reboot your computer
	o save_env:             Save variables to environment block
	o search:               Search devices by file, label, or UUID
	o sendkey:              Emulate keystrokes
	o set:                  Set an environment variable
	o true:                 Do nothing, successfully
	o unset:                Unset an environment variable
	o uppermem:             Set the upper memory size
				

	(fd0)
				

	(hd0,1)
				

	(fd0)  /dev/fd0
	(hd0)  /dev/hda
				

	menuentry 'Linux 3.3.10' {
	<... >
	}
				

At first glance, the two versions do not differ much. However, there are some obvious differences:

The GRUB Legacy definitions for the menu-entries are stored in /boot/grub/menu.lst. On some systems you may find a grub.conf ^[2] link in the /etc or /boot/grub directory. Because GRUB accesses the file directly, any changes in that file will impact the bootloader immediately.

On systems with the Legacy bootloader, GRUB shell is available to install and emulate it. This shell emulates the boot loader and can be used to install the boot loader. It also comes in handy to inspect your current set up and modify it. To start it up (as root) simply type grub. In the following example we display the help screen:

	# grub
	grub> help
	blocklist FILE                         boot
	cat FILE                               chainloader [--force] FILE
	color NORMAL [HIGHLIGHT]               configfile FILE
	device DRIVE DEVICE                    displayapm
	displaymem                             find FILENAME
	geometry DRIVE [CYLINDER HEAD SECTOR [ halt [--no-apm]
	help [--all] [PATTERN ...]             hide PARTITION
	initrd FILE [ARG ...]                  kernel [--no-mem-option] [--type=TYPE]
	makeactive                             map TO_DRIVE FROM_DRIVE
	md5crypt                               module FILE [ARG ...]
	modulenounzip FILE [ARG ...]           pager [FLAG]
	partnew PART TYPE START LEN            parttype PART TYPE
	quit                                   reboot
	root [DEVICE [HDBIAS]]                 rootnoverify [DEVICE [HDBIAS]]
	serial [--unit=UNIT] [--port=PORT] [-- setkey [TO_KEY FROM_KEY]
	setup [--prefix=DIR] [--stage2=STAGE2_ terminal [--dumb] [--timeout=SECS] [--
	testvbe MODE                           unhide PARTITION
	uppermem KBYTES                        vbeprobe [MODE]

	grub >_
			

Other GRUB Legacy commands include the blocklist command, which can be used to find out on which disk blocks a file is stored, or the geometry command, which can be used to find out the disk geometry. You can create new (primary) partitions using the partnew command, load an initrd image using the initrd command, and many more. All options are described in the GRUB documentation. GRUB is part of the GNU software library and as such is documented using the info system. On most systems there is a limited man page available as well.

The initial boot process , upon boot, the BIOS accesses the initial sector of the hard disk, the so-called MBR (Master Boot Record), loads the data found there in memory and transfers execution to it. If GRUB is used, the MBR contains a copy of the first stage of GRUB, which tries to load stage 2.

To be able to load stage 2, GRUB needs to have access to code to handle the filesystem(s). There are many filesystem types and the code to handle them will not fit within the 512 byte MBR, even less so since the MBR also contains the partitioning table. The GRUB parts that deal with filesystems are therefore stored in the so-called DOS compatibility region. That region consists of sectors on the same cylinder where the MBR resides (cylinder 0). In the old days, when disks were adressed using the CHS (Cylinder/Head/Sector) specification, the MBR typically would load DOS. DOS requires that its image is on the same cylinder. Therefore, by tradition, the first cylinder on a disk is reserved and it is this space that GRUB uses to store the filesystem code. That section is referred to as stage 1.5. Stage 1.5 is commonly referred to as the core.img; it is constructed from several files by the installer, based on the filesystem(s) grub needs to support during boot.

Stage 2 contains most of the boot-logic. It presents a menu to the end-user and an additional command prompt, where the user can manually specify boot-parameters. GRUB is typically configured to automatically load a particular kernel after a timeout period. Once the end-user made his/her selection, GRUB loads the selected kernel into memory and passes control on to the kernel. At this stage GRUB can pass control of the boot process to another loader using chain loading if required by the operating system.

In Linux, the grub-install command is used to install stage 1 to either the MBR or within a partition.

The regular boot process is the process that normally takes place when (re)booting the system. This process can be influenced by the GRUB prompt. What can be influenced will be discussed in the following sections, but first we must activate the prompt.

	# telinit 1
				

	ether=5,0x300,eth0 ether=11,0x340,eth1
					

For many decades, the system BIOS (Basic Input Output System) took care of hardware and software initialization during the boot process. Early BIOS versions required manual configuration of physical jumpers on the motherboard. Later versions replaced the manual jumper routine by a software menu, capable of providing an interface to configure the most elementary computer settings. As convenient as this may sound, the constant evolution of computer systems evolved to a point where even the most sophisticated BIOS software proved to have its limitations. To combat these limitations, Intel developed the EFI (Extensible Firmware Interface) system in 1998 as a BIOS replacement. The EFI system dit not catch on, until the standard was adopted by the UEFI Forum around 2005. The standard was then (re)branded from EFI to UEFI (Universal Extensible Firmware Interface). UEFI is sometimes also referred to as (U)EFI. Linux kernel 3.15 and newer should be able to use the UEFI advantages.

What are these advantages you may ask? To answer that question we have to look at the BIOS limitations first. One of the limitations of BIOS systems is noticable when booting operating systems. Traditionally, a BIOS can be configured to use one or more boot devices in a specific order. A boot device can be an optical drive, a harddrive, a portable USB volume or a network interface card. After the BIOS has performed the POST (Power On Self Test), each configured boot device will be checked for the existence of a boot loader. The first bootloader detected will be loaded. In case of a harddrive, the BIOS expects the bootloader to be located at sector 0 or the MBR(Master Boot Record). Since the MBR only allows for a small amount of data (446 bytes) to be stored, the MBR usually contains instructions that point to another piece of code on disk. This two stage approach is known as chainloading. This other piece of code could then consist of a boot manager. A boot manager is capable of loading operating systems located at various locations on the storage volumes. Both the first and second stage of the boot code have to be stored within the first MegaByte of available storage on the harddrive.

UEFI uses a different approach. Instead of being limited to the MBR contents of one specific drive, UEFI reads boot data from an ESP partition. ESP stands for EFI System Partition. The ESP is a designated boot partition. The filesystem is usually of the type FAT , and it can hold any size of bootloader, or even multiple ones. On Linux systems, the ESP is usually mounted as /boot/efi. Underneath that mountpoint will be a directory structure that depends on the Operating System in use. The boot files located within those directories carry a .efi extension. With UEFI, the UEFI software acts as a mini-bootloader looking for filenames ending in .efi within pre-defined locations. On a Fedora based system, the contents of the ESP may look as follows:

	# cd /boot/efi/
	# ls -a
	.  ..  EFI
	#  cd EFI
	#  ls
	BOOT  fedora
	# ls -l BOOT
	total 1332
	-rw-r--r-- 1 root root 1293304 May 17  2016 BOOTX64.EFI
	-rw-r--r-- 1 root root   66072 May 17  2016 fallback.efi
	# ls -l fedora/
	total 3852
	-rw-r--r-- 1 root root     104 May 17  2016 BOOT.CSV
	drwxr-xr-x 2 root root    4096 Sep 28 22:17 fw
	-rwxr-xr-x 1 root root   70864 Sep 28 22:17 fwupx64.efi
	-rw-r--r-- 1 root root 1276192 May 17  2016 MokManager.efi
	-rw-r--r-- 1 root root 1293304 May 17  2016 shim.efi
	-rw-r--r-- 1 root root 1287000 May 17  2016 shim-fedora.efi
			

In the example above, every file ending in .efi can add functionality to the UEFI system. So, whereas BIOS based systems depend on harddrive metadata to boot up a system, UEFI based systems are capable of reading files within the ESP portion of the harddrive. UEFI offers backwards compatibility towards legacy BIOS functions, while at the same time offering more advanced functions for modern computers. Computers using BIOS software have trouble dealing with todays 8TB harddrives. UEFI based computers are able to use GPT disk layouts that defeat the 2TB partition limit of their BIOS counterparts. The UEFI software comes with network support for IPv4 and IPv6. TCP and UDP are supported, and booting remote boot media is supported using TFTP and even HTTP. Booting over HTTP does require UEFI 2.5 or newer. Version 2.5 was released in Januari 2016.

LPIC-2 exam candidates should be aware of the possibility to switch between UEFI and Legacy BIOS boot modes on modern computers. Despite the advantages that UEFI may have, there are also requirements that should be met. The .efi boot files are expected to be located beneath a certain path. When Secure Boot is enabled, the boot code has to be digitally signed. Otherwise, systems may encounter boot issues. When troubleshooting boot issues on a modern Linux computer, try to distinguish MBR from GPT disk layouts. When using the UEFI boot mode, confirm that the Linux distribution in use can also handle UEFI boot. When Secure Boot is enabled, confirm that the required conditions are met. When in doubt, switch back to “Legacy BIOS” or equivalent within the UEFI interface. When booting from USB, it may be necessary to enable 'Legacy USB' settings for Mass Storage Devices in the UEFI interface.

NVMe.  In the previous chapter, 8TB harddrives are mentioned as a result of recent computer storage evolution. These conventional SATA (Serial Advanced Technology Attachmenti) harddrives have moving parts, and are controlled using a protocol called AHCI (Advanced Host Configuration Interface). In recent years, SSD (Solid State Disk) harddrives have become more popular. One of the advantages of these drives is the lack of moving parts. This makes SSD harddrives not only more energy efficient but also faster than mechanical harddrives. Because the SSD drives have to be compatible with existing computers, they are connected with the same SATA connector mechanical harddrives use. And they also use the same AHCI protocol. This protocol was initially designed with mechanical harddrives in mind. AHCI uses 1 queue with 32 commands to control the harddrive. This poses a bottleneck for the newer generation of SSD harddrives. To combat this bottleneck, a new technology called NVMe (Non Volatile Memory Express) has been developed. NVMe allows SSD harddrives to connect to a NVMe controller that is connected to the PCI-E bus on the motherboard. The SSD harddisk is then controlled using the NVMHCI (Non Volatile Memory Host Configuration Interface) protocol. Instead of 1 queue holding 32 commands at a time, the SSD can now be controlled using 65.000 queues holding up to 65.000 commands each. This is possible because the PCI-E bus is much faster than the SATA bus. The latest generation of fast SSD harddrives can achieve throughput speeds up to seven times faster using NVMe when compared to PCI-E connected AHCI harddrives.

Just as traditional harddrives connected to a Linux computer are represented by /dev/hda* or /dev/sda* references, NVMe harddrives are represented by /dev/nvme* within the Linux filesystem tree. When working with these harddrives, be aware that the disk notation starts at 0, but the namespace and partition on disk start at 1. Therefore, the first partition on the first namespace on the first NVMe harddrive of a system is represented by /dev/nvme0n1p1. More about UEFI and NVMe booting at 204.2