contact@linuxtpoint.com
Linuxtpoint
Candid photograph of a Linux server terminal with a soft olive-green glow against a dark slate background, conveying a calm technical atmosphere.

Step-by-step guides for system administrators — covering command-line basics, web server setup, and preparation material for technical interviews.

Browse Tutorials

Troubleshooting GRUB2 boot failures and rescue mode

Troubleshooting boot issues with GRUB2 and rescue mode begins by identifying the failed boot stage. The GRUB2 bootloader may fail before loading an operating system, fail to find a kernel, or hand control to an emergency shell because the root filesystem is unavailable.

Symptoms include a missing GRUB menu, “no such device”, filesystem UUID errors, endless reboots and the dracut emergency target. A live rescue image supplies filesystem and package tools without trusting the installed system.

Work from evidence, not assumptions. Record firmware mode, disk layout, LVM names and exact errors before changing anything. Snapshot cloud volumes, keep offline backups and never repair an unidentified disk; storage mistakes can turn an outage into data loss.

Australian organisations often mix Fedora workstations with RHEL or CentOS Stream servers, although UEFI, Secure Boot and LVM layouts vary. Use paths and package names reported by the installed release rather than copying blindly.

Confirm the failed boot stage

First establish whether firmware reached GRUB. A GRUB rescue prompt or menu suggests that firmware and part of the boot chain work. Record lsblk -f, blkid, findmnt and, where available, efibootmgr -v.

If firmware reports no bootable device, inspect UEFI entries and the EFI System Partition. On Legacy BIOS, suspect the MBR, partition layout or GRUB stage 1. Rescue mode helps only after you can access the installed root filesystem.

Read the first meaningful error. A missing /boot points to mounting, an unknown UUID often comes from /etc/fstab, and kernel errors suggest a damaged boot directory or incomplete initramfs.

Build a rescue environment

Create rescue media on a FAT32 USB and boot it in the server’s UEFI or Legacy BIOS mode. A current Fedora or RHEL live image provides lsblk, blkid, dracut and a shell; confirm that it includes the required LVM and encryption tools.

Attach storage and identify it with lsblk. Activate LVM with vgchange -ay and open LUKS with cryptsetup open where needed. Mount /, /boot and /boot/efi separately when applicable, then enter the installed system with chroot.

Bind-mount /dev, /proc and /sys inside the chroot if required. Keep rescue networking available for packages and preserve application recovery notes; for a multilingual WordPress estate, the linked multilingual WordPress comparison can guide localisation-specific restoration checks.

Inspect boot and storage

Inside the chroot, compare blkid with /etc/fstab. Missing devices or changed UUIDs can prevent root mounting. Use findmnt --verify after corrections, and confirm that the EFI System Partition is FAT32 and mounted at /boot/efi.

Check df -h /boot, permissions and kernel files. The kernel, vmlinuz image and matching initramfs must belong together; lsinitrd can verify their contents. A full boot partition or interrupted upgrade can leave GRUB without a valid boot target.

Inspect storage health before forcing repairs. Read kernel messages and SMART data, and check an unmounted filesystem only after backup. RAID recovery needs correct metadata and an assembled array, not grub2-install against an arbitrary member.

Repair GRUB2 safely

For Legacy BIOS, mount /boot, enter the chroot and commonly run grub2-install --recheck --boot-directory=/boot /dev/sda. For UEFI, commonly run grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB. Replace disk and architecture values deliberately.

Regenerate the configuration with grub2-mkconfig -o /boot/grub2/grub.cfg, then review it for expected kernels and UUIDs. If firmware lacks the EFI entry, use efibootmgr or boot removable media once; --no-nvram may be needed in rescue.

At the GRUB rescue prompt, ls, set root, prefix, insmod normal and normal can reveal a damaged prefix or missing module. Secure Boot can reject unsigned GRUB binaries, so use the distribution’s signed shim and bootloader packages rather than disabling checks casually.

Resolve common failures

Fix fstab UUID mismatches before regenerating GRUB2. A correct menu can still drop into an emergency shell when /, /boot or swap cannot mount. After editing, reload systemd metadata and test each required mount before rebooting.

Rebuild a missing or stale initramfs with dracut --force --kver VERSION /boot/initramfs-VERSION.img, using the installed kernel version. Confirm that GRUB entries use linux16 or linuxefi as appropriate and that each initrd path resolves.

After booting, restore the application layer in order: systemctl daemon-reload, nginx -t, then systemctl restart nginx. The broader Linux web server guidance covers reverse proxies, certificates and service checks that belong behind a successful system boot.

Recovery readiness across Australian operations

Recovery readiness matters in Australia. Cloud volumes in Sydney, Melbourne and Brisbane benefit from snapshots and console access, while remote sites need tested physical-console procedures. Daylight-saving changes to Australian Eastern Time can expose a firmware clock left on local time rather than UTC; Adelaide’s half-hour offset and Perth’s UTC+8 also need accurate records.

Protect sensitive material. Systems subject to the Australian Privacy Principles and Notifiable Data Breaches scheme should keep customer identifiers out of public logs. For imported replacement disks, retain invoices because Australian customs and GST clearance can delay recovery. The visible symptom then narrows the likely layer:

Symptom Likely layer Rescue check Corrective action
No bootable device Firmware, ESP or MBR efibootmgr -v, partition layout Correct boot order or reinstall boot code
Missing GRUB menu Firmware or GRUB ls, insmod normal Restore firmware entry or reinstall GRUB
Unknown UUID fstab or root mount blkid, findmnt --verify Correct UUID and test mounts
Emergency shell after GRUB Initramfs or kernel ls /boot, journalctl Rebuild initramfs or fix root
Bootloader rejected Secure Boot Signatures, firmware log Use signed bootloader packages

The durable lesson is to identify the failed boot stage, work from a verified rescue environment and change only what evidence supports. A written disk map, current backup and tested restore path turn a frightening outage into controlled recovery.