Chapter 1 Working With the GRUB 2 Bootloader and Configuring Boot Services

This chapter describes the Oracle Linux boot process and how to configure and use the GRUB 2 bootloader and boot-related kernel parameters.

1.1 About the Boot Process

Understanding the Oracle Linux boot process can help you troubleshoot problems when booting a system. The boot process involves several files and errors in these files is the usual cause of boot problems. Boot processes and configuration differ depending on whether your hardware uses UEFI firmware or legacy BIOS to handle system boot.

1.1.1 About UEFI-Based Booting

On a UEFI-based system running the Oracle Linux release, the system boot process uses the following sequence:

  1. The system's UEFI firmware performs a power-on self-test (POST) and then locates and initializes peripheral devices including the hard disk.

  2. UEFI searches for a GPT partition with a specific globally unique identifier (GUID) that identifies it as the EFI System Partition (ESP), which contains EFI applications such as boot loaders. In case of the presence of multiple boot devices, the UEFI boot manager determines the appropriate ESP to use, based on the order that is defined in the boot manager. With the efibootmgr tool, you can define a different order, if you do not want to use the default definition.

  3. The UEFI boot manager checks to determine whether Secure Boot is enabled. If Secure Boot is not enabled, the Boot Manager runs the GRUB 2 boot loader on the ESP.

    Otherwise, the boot manager requests a certificate from the boot loader and validates this against keys stored in the UEFI Secure Boot key database. To handle the certificate validation process, the environment is configured to perform a 2-stage boot process and the shim.efi application that is responsible for certification is loaded first before loading the GRUB 2 boot loader. If the certificate is valid, the boot loader runs and, in turn, validates the kernel that it is configured to load.

  4. The boot loader loads the vmlinuz kernel image file into memory and extracts the contents of the initramfs image file into a temporary, memory-based file system (tmpfs).

  5. The kernel loads the driver modules from the initramfs file system that are needed to access the root file system.

  6. The kernel starts the systemd process with a process ID of 1 (PID 1). See Section 2.1, “About the systemd Service Manager”.

  7. systemd runs any additions processes defined for it.

    Note

    Specify any other actions to be processed during the boot process by defining your own systemd unit. This method is the preferred approach than using the /etc/rc.local file.

1.1.2 About BIOS-Based Booting

On a BIOS-based system running the Oracle Linux release, the boot process is as follows:

  1. The system's BIOS performs a power-on self-test (POST), and then locates and initializes any peripheral devices including the hard disk.

  2. The BIOS reads the Master Boot Record (MBR) into memory from the boot device. The MBR stores information about the organization of partitions on that device, the partition table, and the boot signature which is used for error detection. Additionally, the MBR includes the pointer to the boot loader program (GRUB 2). The boot program itself can be on the same device or on another device.

  3. The boot loader loads the vmlinuz kernel image file into memory and extracts the contents of the initramfs image file into a temporary, memory-based file system (tmpfs).

  4. The kernel loads the driver modules from the initramfs file system that are needed to access the root file system.

  5. The kernel starts the systemd process with a process ID of 1 (PID 1). See Section 2.1, “About the systemd Service Manager” for more information.

  6. systemd runs any additional processes defined for it.

    Note

    Specify any other actions to be processed during the boot process by defining your own systemd unit. This method is the preferred approach than using the /etc/rc.local file.

1.2 About the GRUB 2 Bootloader

GRUB 2 can load many operating systems in addition to Oracle Linux and it can chain-load proprietary operating systems. GRUB 2 understands the formats of file systems and kernel executables, which allows it to load an arbitrary operating system without needing to know the exact location of the kernel on the boot device. GRUB 2 requires only the file name and drive partitions to load a kernel. You can configure this information by using the GRUB 2 menu or by entering it on the command line.

GRUB 2 behavior is based on configuration files. On BIOS-based systems, the configuration file is /boot/grub2/grub.cfg. On UEFI-based systems, the configuration file is /boot/efi/EFI/redhat/grub.cfg. Each kernel version's boot paramaters are stored in independent configuration files in /boot/loader/entries. Each kernel configuration is stored with the file name machine_id-kernel_version.el8.arch.conf.

Note

Do not edit the GRUB 2 configuration file directly.

The grub2-mkconfig command generates the configuration file using the template scripts in /etc/grub.d and menu-configuration settings taken from the configuration file, /etc/default/grub.

The default menu entry is determined by the value of the GRUB_DEFAULT parameter in /etc/default/grub. The value saved allows you to use the grub2-set-default and grub2-reboot commands to specify the default entry. grub2-set-default sets the default entry for all subsequent reboots and grub2-reboot sets the default entry for the next reboot only.

If you specify a numeric value as the value of GRUB_DEFAULT or as an argument to either grub2-reboot or grub2-set-default, GRUB 2 counts the menu entries in the configuration file starting at 0 for the first entry.

You can use the grubby command to view and manage your kernels.

Use the following command to display all of the kernels that are installed and configured on your system:

sudo grubby --info=ALL

To configure a specific kernel as the default boot kernel, run:

sudo grubby --set-default /boot/vmlinuz-4.18.0-80.el8.x86_64

You can also use the grubby command to update a kernel configuration entry to add or remove kernel boot arguments, for example:

sudo grubby --remove-args="rhgb quiet" --args=rd_LUKS_UUID=luks-39fec799-6a6c-4ac1-ac7c-1d68f2e6b1a4 --update-kernel /boot/vmlinuz-4.18.0-80.el8.x86_64

For more information about the grubby command, see the grubby(8) manual page, which you can access by running the man grubby command.

For more information about using, configuring, and customizing GRUB 2, see the GNU GRUB Manual, which is also installed as /usr/share/doc/grub2-tools-2.00/grub.html.

1.3 Kernel Boot Parameters

The following table describes some commonly used kernel boot parameters.

Option

Description

0, 1, 2, 3, 4, 5, or 6, or systemd.unit=runlevelN.target

Specifies the nearest systemd-equivalent system-state target to match a legacy SysV run level. N can take an integer value between 0 and 6.

Systemd maps system-state targets to mimic the legacy SysV init system.

For a description of system-state targets, see Section 2.2, “About System-State Targets”.

1, s, S, single, or systemd.unit=rescue.target

Specifies the rescue shell. The system boots to single-user mode prompts for the root password.

3 or systemd.unit=multi-user.target

Specifies the systemd target for multi-user, non-graphical login.

5 or systemd.unit=graphical.target

Specifies the systemd target for multi-user, graphical login.

-b, emergency, or systemd.unit=emergency.target

Specifies emergency mode. The system boots to single-user mode and prompts for the root password. Fewer services are started than when in rescue mode.

KEYBOARDTYPE=kbtype

Specifies the keyboard type, which is written to /etc/sysconfig/keyboard in the initramfs.

KEYTABLE=kbtype

Specifies the keyboard layout, which is written to /etc/sysconfig/keyboard in the initramfs.

LANG=language_territory.codeset

Specifies the system language and code set, which is written to /etc/sysconfig/i18n in the initramfs.

max_loop=N

Specifies the number of loop devices (/dev/loop*) that are available for accessing files as block devices. The default and maximum values of N are 8 and 255.

nouptrack

Disables Ksplice Uptrack updates from being applied to the kernel.

quiet

Reduces debugging output.

rd_LUKS_UUID=UUID

Activates an encrypted Linux Unified Key Setup (LUKS) partition with the specified UUID.

rd_LVM_VG=vg/lv_vol

Specifies an LVM volume group and volume to be activated.

rd_NO_LUKS

Disables detection of an encrypted LUKS partition.

rhgb

Specifies that the Red Hat graphical boot display should be used to indicate the progress of booting.

rn_NO_DM

Disables Device-Mapper (DM) RAID detection.

rn_NO_MD

Disables Multiple Device (MD) RAID detection.

ro root=/dev/mapper/vg-lv_root

Specifies that the root file system is to be mounted read only, and specifies the root file system by the device path of its LVM volume (where vg is the name of the volume group).

rw root=UUID=UUID

Specifies that the root (/) file system is to be mounted read-writable at boot time, and specifies the root partition by its UUID.

selinux=0

Disables SELinux.

SYSFONT=font

Specifies the console font, which is written to /etc/sysconfig/i18n in the initramfs.

The kernel boot parameters that were last used to boot a system are recorded in /proc/cmdline, for example:

sudo cat /proc/cmdline
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-80.el8.x86_64 root=/dev/mapper/ol-root ro crashkernel=auto \
resume=/dev/mapper/ol-swap rd.lvm.lv=ol/root rd.lvm.lv=ol/swap rhgb quiet

For more information, see the kernel-command-line(7) manual page.

1.4 Modifying Kernel Boot Parameters Before Booting

To modify boot parameters before booting a kernel, follow these steps:

  1. When the GRUB boot menu appears at the beginning of the boot process, use the arrow keys to highlight the required kernel and press the space bar.

  2. Press E to edit the boot configuration for the kernel.

  3. Use the arrow keys to bring the cursor to the end of the line that starts with linux, which is the boot configuration line for the kernel.

  4. Modify the boot parameters.

    You can add parameters such as systemd.target=runlevel1.target, which instructs the system to boot into the rescue shell.

  5. Press Ctrl+X to boot the system.

1.5 Modifying GRUB 2 Kernel Boot Parameters

To modify the boot parameters for the GRUB 2 configuration so that these parameters are applied by default at every reboot, follow these steps:

  1. Edit /etc/default/grub and modify the parameters in the GRUB_CMDLINE_LINUX definition, for example:

    GRUB_CMDLINE_LINUX="vconsole.font=latarcyrheb-sun16 vconsole.keymap=uk 
    crashkernel=auto  rd.lvm.lv=ol/swap rd.lvm.lv=ol/root biosdevname=0 
    rhgb quiet systemd.unit=runlevel3.target"

    This example adds the parameter systemd.unit=runlevel3.target so that the system boots into multi-user, non-graphical mode by default.

  2. Rebuild /boot/grub2/grub.cfg:

    sudo grub2-mkconfig -o /boot/grub2/grub.cfg

    The change takes effect for subsequent system reboots of all configured kernels.

Note

For systems that boot with UEFI, the grub.cfg file is located in the /boot/efi/EFI/redhat directory because the boot configuration is stored on a dedicated FAT32-formatted partition.

After the system has successfully booted, the EFI folder on that partition is mounted inside the /boot/efi directory on the root file system for Oracle Linux.