Practical Recovery of Linux GRUB

#Linux #GRUB Practical RecoveryFault Phenomenon and Root Cause Analysis

After a system upgrade or unexpected power outage, the following prompt appears on boot:

error: symbol 'grub_is_lockdown' not found.
Entering rescue mode...
grub rescue>

This issue is common in Debian/Ubuntu system upgrade scenarios and is essentially a compatibility problem with the GRUB package or file corruption. Based on the depth of the fault, it can be divided into two levels:

  1. Physical Layer Failure: Disk partition table corruption prevents GRUB from locating the boot sector
  2. Logical Layer Failure: Corruption of GRUB program files or version conflicts (e.g., upgrading to a flawed version 2.02+dfsg1-20+deb10u4)

Repair Plan Design (Example for Ubuntu 18.04 EFI Boot)

1. Environment Preparation

  • Create a bootable Ubuntu 20.04 USB drive (recommended using Rufus tool)
  • Ensure Secure Boot is disabled in BIOS and set to UEFI boot mode
  • Prepare a network connection (for downloading repair packages)

2. Key Repair Steps

1. System Mounting and Environment Initialization

# Enter root privileges
sudo -i

# Mount the root partition (adjust device name according to actual partition)
mount /dev/sdb2 /mnt           # Mount the system root partition
mount /dev/sdb1 /mnt/boot/efi  # Mount the EFI partition

# Bind the system runtime environment (core step! Ensure available system resources after chroot)
mount -v --bind /proc /mnt/proc
mount -v --bind /dev /mnt/dev
mount -v --bind /sys /mnt/sys

# Synchronize network configuration
mkdir -p /mnt/run/NetworkManager
mount -v --bind /run/NetworkManager /mnt/run/NetworkManager

2. Enter Repair Environment

# Switch to root environment
chroot /mnt

3. GRUB Repair Strategies (Comparison of Two Plans)

Plan Operation Applicable Scenarios
Version Rollback<span>apt install grub-common=2.02+dfsg1-20+deb10u1</span> Fix known version defects (e.g., Debian Buster 10u4 version bug) Failure occurs immediately after GRUB upgrade
Complete Rebuild<span>grub-install --target=x86_64-efi --bootloader-id=Ubuntu</span><span>update-grub</span> Use when file corruption is severe or version rollback is ineffective Repair after physical partition damage

4. Special Issue Handling

  • Dependency Conflict Resolution: Install DEB packages in order (grub-efi → grub2-common → grub-efi-amd64)
  • EFI Partition Anomalies: Check FAT32 file system and rebuild <span>/boot/efi</span> directory structure

In-Depth Technical Principle Analysis

1. Secrets of the chroot Mechanism

By binding mount special directories such as <span>/proc</span>, <span>/dev</span>, and <span>/sys</span>, a complete system runtime sandbox is constructed. Among them, binding <span>/run/NetworkManager</span> ensures DNS configuration inheritance, solving the package download failure caused by network issues in the repair environment.

2. GRUB Version Compatibility Pitfalls

If you encounter the following during a Debian system upgrade:

WARNING: Device /dev/sda1 not initialized in udev database...

It is likely that the new version of GRUB has compatibility issues with hardware drivers. In this case, forcibly rolling back to version 2.02+dfsg1-20+deb10u1 can avoid this defect.

Post-Maintenance Recommendations

  1. Disable Automatic Upgrades by locking the critical version with <span>apt-mark hold grub-common</span>
  2. Regularly Backup Boot Sector
dd if=/dev/sda of=grub_backup bs=446 count=1  # Backup MBR
tar zcvf grub_cfg_backup.tar /boot/grub/grub.cfg  # Backup configuration

Leave a Comment