Understanding Linux Boot Process and GRUB Configuration

When a Linux system starts, several components work in sequence before a login prompt appears. Firmware checks the hardware, a bootloader selects the operating system, the kernel loads essential drivers, and the initial ramdisk prepares the real root filesystem.

Understanding this chain makes it easier to repair failed boots, change kernel parameters, select an older kernel, or troubleshoot a server that stops before systemd starts. The process is broadly similar across RHEL, CentOS, Fedora, and compatible distributions, although file locations and management commands can vary.

This knowledge is useful for administrators working with physical machines, virtual servers, and cloud instances in Australia. A system hosted in an AWS Sydney region may fail for the same bootloader reason as a workstation in a Brisbane lab, while a remote server in Perth can require extra care because physical console access is limited.

GRUB configuration should be changed deliberately. A small syntax error or an incorrect root device can leave a machine unbootable, so keep a recovery ISO, console access, and a tested rollback plan available before editing boot settings.

Firmware And Bootloader Stages

On a BIOS-based machine, firmware performs a power-on self-test and looks for boot code in the disk’s master boot record. With UEFI, firmware reads an executable from the EFI System Partition, usually mounted at /boot/efi. UEFI systems generally provide more flexible boot entries and are now common on new servers and desktops.

GRUB 2 then displays a menu and loads the selected kernel together with its initramfs image. The menu may be hidden when the default entry is used, but pressing Esc or holding Shift during startup can expose it on many systems. The kernel command line shown in the menu is valuable when investigating storage, graphics, or emergency-mode problems.

Useful inspection commands include lsblk -f, findmnt, and efibootmgr -v on UEFI systems. These reveal filesystem identifiers, mount points, and firmware boot order. If a machine in a Sydney rack suddenly reports “no such device”, checking UUIDs is often faster than guessing which disk name changed.

Kernel, Initramfs, And Systemd

After GRUB loads the kernel into memory, Linux unpacks the initramfs. This temporary filesystem contains early userspace tools and drivers needed to locate encrypted volumes, RAID arrays, logical volumes, and the actual root filesystem. Once that filesystem is available, control moves to the system’s configured init program.

On modern distributions, systemd becomes process ID 1. It mounts filesystems, activates swap, starts device services, brings up networking, and selects a target such as graphical.target or multi-user.target. A failed unit can delay startup or send the machine into emergency mode. Review the current boot with journalctl -b, and inspect failed units using systemctl --failed.

RHEL and Fedora administrators commonly rebuild an initramfs with dracut --force after correcting drivers or storage configuration. Avoid running it blindly on a production host: confirm the active kernel with uname -r, preserve a known-good kernel, and verify that /boot has sufficient free space.

GRUB Configuration Files And Tools

The file /etc/default/grub stores broad settings such as the default menu entry, timeout, and kernel arguments. The generated configuration is usually /boot/grub2/grub.cfg on BIOS installations and /boot/efi/EFI/redhat/grub.cfg or a related EFI path on RHEL-family UEFI systems. The exact path can differ, so check the distribution documentation and existing layout first.

On RHEL and CentOS, grub2-mkconfig generates menu content, while grubby is often safer for changing kernel arguments across installed entries. For example, an administrator can inspect entries with grubby --info=ALL. After changing /etc/default/grub, regenerate the configuration with the appropriate command for the machine rather than copying a command from an unrelated Ubuntu guide.

A temporary kernel argument can be tested directly from the GRUB menu by selecting an entry and pressing e. Add the parameter to the line beginning with linux or linux16, then boot with Ctrl+x or F10. This change lasts for one boot, making it a safer way to test options such as systemd.unit=emergency.target or a graphics workaround.

Safe Recovery And Troubleshooting

If a boot fails after a kernel update, select an older kernel from “Advanced options” in GRUB. A successful boot confirms that the hardware and root filesystem may be healthy, narrowing the problem to the newer kernel, modules, or initramfs. Check journalctl -b -1 when the previous boot’s logs are available.

For a damaged configuration, boot from rescue media, mount the installed system under /mnt, and bind-mount /dev, /proc, /sys, and /run before using chroot. On a UEFI host, also mount the EFI System Partition in its expected location. Reinstalling GRUB or rebuilding its configuration should follow a careful identification of the boot disk and firmware mode.

Boot-related work often sits beside routine automation. If a server must restart after kernel maintenance, compare cron and systemd timers so the scheduling method records failures and avoids an unexpected reboot during an Australian business morning.

Operational Practices For Administrators

Keep at least one tested kernel available, monitor /boot usage, and record changes to GRUB arguments in your configuration management system. In environments spanning Melbourne and Sydney, document which console service or hypervisor provides recovery access. A remote hands request can take much longer than a local keyboard session, especially for a smaller Perth site.

Boot security also deserves attention. UEFI Secure Boot can prevent unsigned modules from loading, while full-disk encryption introduces early boot prompts and key-management dependencies. Test kernel updates on a spare VM before applying them to customer-facing systems, including hosts in Australia East or the Sydney cloud region.

Access problems after recovery can be confused with boot problems. Once the system reaches a normal target, verify administrative accounts, group membership, and sudo rules; the guide to managing user accounts covers the relevant usermod and groupadd commands. For administrators who prefer a keyboard-driven workflow, browse source files efficiently when reviewing scripts or configuration tools.

A reliable boot checklist is simple: identify BIOS or UEFI mode, confirm the kernel and initramfs files, inspect GRUB arguments, check failed systemd units, and preserve a working kernel before making changes. Test the procedure on a spare machine, document the exact recovery commands, and keep console access available before touching production boot configuration.