System Boot 2: Cannot Boot Troubleshooting
BIOS Issue
If your system fails to reach the GRUB prompt, the issue could be a corrupted GRUB, a failed hard drive, or an incorrect BIOS boot order. Start by checking the BIOS boot order, as it’s the simplest fix. This problem often occurs when the boot order is changed to boot from external media (e.g., USB, CD-ROM) and isn’t reset afterward.
To access the BIOS settings, press a specific key (e.g., Del, F1, F2, or Esc) during startup. Some BIOS versions allow you to press another key (e.g., F11 or F12) to temporarily change the boot device for a single session. Look for on-screen prompts during boot to identify the correct keys.
Once in the BIOS, navigate to the boot order settings (usually under "Boot" or "Advanced"). Select the primary hard drive as the first boot device. If the system boots successfully, ensure the boot order is saved. If none of the drives work, GRUB may be corrupted, or the hard drive/controller may have failed. In such cases, use a rescue disk to attempt GRUB repair or investigate hardware issues.
GRUB Issue
No GRUB Prompt
If the GRUB prompt doesn’t appear at all during boot, it could indicate that GRUB is either missing or corrupted. This often happens due to a failed GRUB installation, a misconfigured BIOS boot order, or a damaged Master Boot Record (MBR). To resolve this, boot from a live Linux system or rescue disk and reinstall GRUB to the MBR.
Halfway through GRUB Prompt
If the system starts loading GRUB but freezes or crashes midway, the issue might be related to a corrupted GRUB configuration file (grub.cfg) or a problem with the kernel or initrd. Boot into a live system, check the GRUB configuration, and regenerate grub.cfg using the grub-mkconfig command. Also, verify that the kernel and initrd files are intact.
Misconfigured GRUB Prompt
A misconfigured GRUB prompt may appear if there are errors in the grub.cfg file or if the kernel parameters are incorrect. This can prevent the system from booting properly. To fix this, boot into a live system, mount the root partition, and manually edit or regenerate the grub.cfg file. Ensure the correct root device and kernel parameters are specified.
Repair GRUB from the Live System
If GRUB is broken, you can repair it using a live Linux system. Boot into the live environment, open a terminal, and mount the root partition of your installed system. Use the chroot command to switch into the installed system, then reinstall GRUB using grub-install and regenerate the configuration file with grub-mkconfig.
Repair GRUB with a Rescue Disk
A rescue disk (like SystemRescue or a Linux distribution’s installation disk) can help repair GRUB when the system fails to boot. Boot from the rescue disk, mount the root partition, and use tools like grub-install and grub-mkconfig to reinstall GRUB and fix the bootloader. This method is particularly useful when the live system approach isn’t sufficient.
Mounting Issue
Can’t Mount the Root File System
Can’t Mount the Root File System
If the system fails to mount the root file system during boot, it could be due to an incorrect root device, a missing or corrupted initrd, or a filesystem issue. To troubleshoot, boot into a live Linux system, use the lsblk or fdisk -l command to identify the root partition, and check its filesystem with fsck (e.g., fsck /dev/sdX1). Ensure the initrd contains the necessary drivers for the root filesystem.
The Root Kernel Argument
The kernel requires the correct root= argument to locate the root partition. If this argument is missing or incorrect, the system won’t boot. To fix this, interrupt the GRUB boot process, edit the kernel command line, and specify the correct root device (e.g., root=/dev/sdX1). After booting, update the GRUB configuration to ensure the correct argument is used in the future.
The Root Device Changed
If the root device has changed (e.g., due to hardware changes or disk reordering), the system may fail to boot. Boot into a live system, identify the new root device using lsblk or blkid, and update the GRUB configuration (/etc/default/grub and grub.cfg) to reflect the correct device. Regenerate the GRUB configuration with grub-mkconfig -o /boot/grub/grub.cfg.
# lsblk
--------------------------------------------
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 252:0 0 50G 0 disk
├─vda1 252:1 0 1G 0 part /boot
└─vda2 252:2 0 39G 0 part
├─VolGroup-lv_root 253:0 0 509G 0 lvm /
├─VolGroup-lv_log 253:3 0 520G 0 lvm /var/log
└─VolGroup-lv_tmp 253:4 0 510G 0 lvm /tmp
vdb 252:16 0 2T 0 disk
├─vg01-data 253:1 0 40G 0 lvm /opt/cloud
└─vg01-log 253:2 0 2T 0 lvm /opt/cloud/logs
vdc 252:32 0 2T 0 disk
├─VolGroup-lv_root 253:0 0 509G 0 lvm /
├─VolGroup-lv_log 253:3 0 520G 0 lvm /var/log
└─VolGroup-lv_tmp 253:4 0 510G 0 lvm /tmp
vdd 252:48 0 2T 0 disk
vde 252:64 0 2T 0 disk
vdf 252:80 0 2T 0 disk
# blkid
--------------------------------------------
/dev/mapper/vg01-data: UUID="cf79a333-9496-4ec5-b689-7433b718fd82" BLOCK_SIZE="4096" TYPE="ext4"
/dev/vdb: UUID="fHyLyw-1S3L-DQ5P-sgHc-Op7u-6Vod-ONTlTH" TYPE="LVM2_member"
/dev/mapper/VolGroup-lv_tmp: UUID="c362678c-3351-41c1-92f0-5e2394282530" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/vg01-log: UUID="ac349419-2ba3-4934-8ca6-eb2e2a4798ea" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/VolGroup-lv_root: UUID="adcc1a2a-de01-4da6-a04b-3d7e1ca2b81a" BLOCK_SIZE="4096" TYPE="ext4"
/dev/vdc: UUID="JjTce2-JlVA-Afri-6xJ5-Z2Ir-18I0-Rr7Qnd" TYPE="LVM2_member"
/dev/vda2: UUID="zRrlqN-gsUu-NqXo-4QbQ-veaN-F2xV-yH7afm" TYPE="LVM2_member" PARTUUID="1915e056-02"
/dev/vda1: UUID="01d51f5e-dd5d-41aa-aebc-0bf0b510ca2f" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="1915e056-01"
/dev/mapper/VolGroup-lv_log: UUID="0092a525-074c-49dd-84ff-e46c7ab556cd" BLOCK_SIZE="4096" TYPE="ext4"
# cat /etc/default/grub
--------------------------------------------
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="biosdevname=0 net.ifnames=0 crashkernel=auto rd.lvm.lv=VolGroup/lv_root rd.shell=0 quiet"
GRUB_DISABLE_RECOVERY="true"
The Root Partition is Corrupt or Failed
A corrupt or failed root partition can prevent the system from booting. Boot into a live Linux system and use the fsck command to check and repair the filesystem (e.g., fsck /dev/sdX1). If the partition is beyond repair, you may need to restore data from backups and reinstall the system. Use dmesg or journalctl to check for hardware-related errors that might indicate a failing disk.
Can’t Mount Secondary File Systems
Apart from the root file system, there are also other file systems to be mounted on system boot, if these file systems failed to be mounted, the booting process will be interrupted, we can check these file systems in /etc/fstab:
cat /etc/fstab
--------------------------------------------
#
# /etc/fstab
# Created by anaconda on Sun Feb 27 00:31:37 2022
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
/dev/mapper/VolGroup-lv_root / ext4 defaults 1 1
UUID=01d51f5e-dd5d-41aa-aebc-0bf0b510ca2f /boot ext4 nodev 1 2
/dev/mapper/VolGroup-lv_tmp /tmp ext4 defaults,nodev 1 2
/dev/mapper/VolGroup-lv_log /var/log ext4 defaults,nodev,nosuid,noexec 1 2
UUID=cf79a333-9496-4ec5-b689-7433b718fd82 /opt/cloud ext4 defaults 0 0
UUID=ac349419-2ba3-4934-8ca6-eb2e2a4798ea /opt/cloud/logs ext4 defaults 0 0
In the above example, during system boot, the following filesystems will be mounted in the specified order:
Root (
/): The main filesystem for the operating system./boot: Contains the kernel and initrd files./tmp: Used for temporary files./var/log: Stores system logs./opt/cloud: Contains cloud-related data./opt/cloud/logs: Stores cloud-related logs.