Introduction

System boot failures are not frequent, but after enough attempts, even low-probability events can occur. Although having a Ventoy multi-boot USB drive makes system installation a breeze, when a system fails, reinstalling is often easier than repairing it. However, occasionally exploring the repair process can be a valuable learning experience. Interestingly, this time the failure was significant enough to document a tutorial with considerable reference value. The core issues addressed in this tutorial are:

• Repairing boot loss caused by incorrect EFI partition configuration
• Rebuilding UEFI boot entries
• Fixing boot failures caused by fstab issues

Cause of the Failure

For some interesting reasons, I was not allowed to use domestic systems. Therefore, I attempted to install OpenKylin on my USB drive. However, while the USB system is good, the daily 996 work schedule made it a bit too much for the USB drive. So I changed my plan, reallocating partitions on my computer’s disk, freeing up 89GB from a 256GB hard drive with Windows 11 installed to install the OpenKylin system (OpenKylin 2.0 sp1). The desired effect was to boot directly into Windows 11 without any prompts (bypassing grub), keeping it discreet. When in use, I could select the OpenKylin boot entry from the UEFI/BIOS boot selection by pressing F8 (or F12, etc.) during startup. Originally, this was not a difficult task. Friends in the group generally believed that OpenKylin 2.0 sp2 was still somewhat unoptimized and not suitable for office use, so I decided to stick with 2.0 sp1. I booted from the USB drive, selected to enter the OpenKylin live CD (which is a directly runnable operating system), and during installation, set the EFI partition as the /boot/efi mount point, allocating the unallocated space for the new system’s partition, i.e., the / mount point, omitting other mount points. After installation, a reboot was all that was needed. Unfortunately, I made a mistake during the installation by setting a partition on another USB drive as the system’s EFI partition and using it as the /boot/efi mount point.<span>I thought this would hide the OpenKylin system better. It turned out to be well hidden.</span> After shutting down and removing the USB drive, upon rebooting, the OpenKylin system’s boot entry was completely invisible in the UEFI/BIOS boot selection. I thought the issue was minor. I even tried using the DiskGenius tool from the Micro PE tool to forcibly copy the OpenKylin EFI files into the computer’s EFI partition, but it had no effect, only adding more steps to the repair process.<span>Indeed, one should not blindly strive when ignorant.</span> It’s better to learn from AI. The subsequent tutorial is adapted from a response by Tencent Yuanbao.

1. Rebuilding the Boot Files

Phase One: Preparing Tools

1. Boot into the OpenKylin Live USB environment 2. Open the terminal and gain root privileges:

sudo -i

Phase Two: Checking and Analyzing Partition Status

1. View disk partition information:

fdisk -l
# or use a more detailed tool:
parted -l

2. Identify key partitions: • EFI System Partition (ESP): Usually a smaller FAT32 partition (100MB-500MB) • OpenKylin root partition: Usually a larger ext4 partition My partition situation is as follows: • ESP: /dev/sda1 • OpenKylin: /dev/sda5

Note that readers can refer to the subsequent code in this article, but partition codes may differ on different computers and need to be modified accordingly.

Phase Three: Starting to Rebuild the Boot Files

Step 1: Mount the partitions

# Create mount points
mkdir -p /mnt/linux
mkdir -p /mnt/efi

# Mount the partitions; at least the root (/) and EFI partitions must be mounted.
# If other partitions were set during system installation, they should also be mounted appropriately.
mount /dev/sda5 /mnt/linux      # OpenKylin root partition, modify sdaX according to your partition
mount /dev/sda1 /mnt/efi        # EFI System Partition

Step 2: Check the status of the ESP partition

# Check the EFI file system, usually no major issues; if there are, you can search for solutions
fsck -y /dev/sda1

# View the contents of the ESP partition
ls -la /mnt/efi/EFI/

The current ESP partition should not have the OpenKylin EFI, or it may exist but not boot the system properly, requiring regeneration.

Step 3: Reinstall the OpenKylin EFI

# Mount necessary system directories
mount --bind /dev /mnt/linux/dev
mount --bind /proc /mnt/linux/proc
mount --bind /sys /mnt/linux/sys
mount --bind /run /mnt/linux/run

# Since we need to switch to the OpenKylin system on the sda5 partition, we need to mount the ESP partition (i.e., the EFI partition) again.
# If other partitions were set during system installation, they should also be mounted appropriately (you can check the mount points from its /etc/fstab file).
mkdir -p /mnt/linux/boot/efi
mount /dev/sda1 /mnt/linux/boot/efi

# Switch to the system environment in the mounted partition
chroot /mnt/linux

# Completely reinstall GRUB
# Subsequently, the EFI partition will have the system's boot file /EFI/openkylin/grubx64.efi
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=openkylin --recheck

# Update GRUB configuration; grub will automatically recognize other systems in the hard disk partitions and add them to the grub boot menu
update-grub

# Unmount the EFI partition
umount /boot/efi

# Exit chroot and return to the live USB environment
exit

# Unmount
sudo umount /mnt/linux/{dev,proc,sys,run}
sudo umount /mnt/linux
sudo umount /mnt/efi

Problems Encountered

In fact, this step took a long time and was repeated several times, but it did not fix the system. The reasons are twofold: first, I had previously manually modified the EFI partition using the DiskGenius tool from Micro PE, which caused the program to detect errors when checking the EFI file system, so I had to copy it to AI for a solution; second, AI is not omnipotent, and the code it provides sometimes contains errors, requiring basic judgment to correct or ask AI again; third, and most importantly, my knowledge is limited, and I do not fully understand the principles. Essentially, this step’s core task is to mount another system environment (the disk system) within a system environment (Live USB) and switch to the mounted system to work, injecting a boot EFI file into the disk’s ESP partition. However, this is still not the end. We also need to let the hardware discover this boot OpenKylin EFI file so that it can be started by the hardware.

2. Writing Boot Entry Information to the Motherboard’s NVRAM

This computer uses UEFI + GPT boot mode, so after rebuilding the EFI file, we also need to write the boot entry information (a “pointer” to the EFI file) into the motherboard’s NVRAM to complete the repair.

1. Install efibootmgr

sudo apt install efibootmgr

2. Use efibootmgr to create a boot entry

# Use efibootmgr to create a boot entry
efibootmgr -c -d /dev/sda -p 1 -L "OpenKylin" -l \\EFI\\openkylin\\grubx64.efi

# Command explanation:
#    1.-c: Create a new boot entry (create)
#    2.-d /dev/sda: Specify the disk device containing the EFI System Partition (ESP)
#    3.-p 1: Specify the partition number of the ESP on that disk
#    4.-L "OpenKylin": Set the name displayed in the BIOS/UEFI menu for the boot entry
#    5.-l \\EFI\\openkylin\\grubx64.efi: Specify the path of the EFI boot file (relative to the root directory of the ESP)

# View current boot entries; if "OpenKylin" appears, the repair is successful
efibootmgr -v

# Set the boot order; I did not complete this in bash but modified it from the BIOS settings

3. Entering the System

After performing these operations, the OpenKylin boot entry indeed appeared. However, I was still unable to enter the system. I then considered reinstalling directly, but later thought it might be an issue with the /etc/fstab file? After modifying its contents, I was able to enter the system normally. Here is the original content of my /etc/fstab file, where you can see that I set two partitions for the system: one EFI partition (formatted as vfat), set as the /boot/efi mount point, and one ext4 formatted partition, set as the root mount point “/”.

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# /dev/sda5
UUID=eaabe0fr-a3f2-4491-4656-3258rt03327e	/          	ext4       rw,relatime	0 1

# /dev/sdb1
UUID=46R3-E452  /boot/efi  vfat  defaults,umask=0077  0  0

Since the EFI partition I initially set during system installation was on another USB drive, I now need to change it back to the computer’s disk ESP partition (sda1), so I need to modify the “UUID= ****” content. By using the command <span>sudo blkid</span>, I found the UUID number corresponding to the ESP partition and copied it. Then, I used <span>sudo vi /etc/fstab</span> with the vi editor to modify the contents, completing the final repair work. Readers can search for vi syntax; if you dislike vi syntax, you can copy the file to the desktop, modify it, and then use a command to copy it back; alternatively, you can also read and write using Python under root privileges. This file specifies the various mount points of the system, so we can also modify this file to allow the system to automatically mount other partitions on the computer during startup; or by modifying this file, add (or remove) other mount points, or set or cancel swap partitions.

Conclusion

After completing the repair, I successfully entered the system. However, I couldn’t help but ask AI again whether these three repair steps—repairing the boot files (EFI files), writing UEFI boot entries to hardware, and fixing the fstab file—are all necessary? Especially since the second step was something I had previously overlooked. The response I received was that the first two steps are indeed necessary, but the last step only needs to be repaired when the partition UUID/mount point is incorrect, such as mistakenly using device names (like /dev/sda1) instead of UUIDs; the ESP partition not correctly pointing to /boot/efi; etc. Thus, I have accumulated some experience. Here are some principles: The principles of different boot methods vary, and thus the repair methods are also different.

Traditional BIOS/MBR Boot Method

This type was the mainstream configuration for older computers before 2010 (yes, these computers are indeed old). Disk partitioning (MBR): an old partition table that supports a maximum of 4 primary partitions and manages disks up to 2TB in size. Motherboard firmware (BIOS): the basic input/output system stored in a read-only chip on the motherboard, responsible for initializing hardware and the first stage of the boot process, with hardware settings (such as the order of booting from hard drives, USB drives, CDs, networks, etc.) stored in a CMOS memory powered by a button battery, which is modifiable. For this type, all boot information is stored in fixed locations on the disk (MBR and partition PBR), and the boot process is as follows:(1) Power on → Motherboard BIOS initializes and reads settings from CMOS(2) Read disk MBR → Execute code in the master boot record(3) Activate partition → Load partition boot record (PBR)(4) Boot loader → Execute the second stage boot program (like GRUB)(5) Boot operating system → Load kernel and complete boot

Modern UEFI/GPT Boot Method

This is currently the absolute mainstream boot method. Disk partitioning (GPT): a modern partition table that supports almost unlimited primary partitions and can manage extremely large disks. Motherboard firmware (UEFI): Unified Extensible Firmware Interface, a standard specification that replaces BIOS. Motherboard manufacturers implement it as updatable firmware (often still referred to as BIOS in daily communication), with more powerful functions. This type of boot uses a “pointer + file” separation mode: pointers are stored in the motherboard’s NVRAM (non-volatile memory that does not require a battery) and record the name and path of each boot entry. The actual boot files (like grubx64.efi) are stored in a separate EFI System Partition (ESP) (formatted as FAT32). The boot process for this type is as follows:(1) Power on → UEFI firmware initializes(2) Read NVRAM → Get the EFI file path from the boot menu(3) Locate EFI file → Search for .efi boot files in the EFI System Partition (ESP)(4) Execute boot program → Load the operating system kernel(5) Boot operating system → Complete system boot

Corresponding Repair Methods

When encountering boot issues,(1) BIOS/MBR systems: Use tools like bootrec or grub-install to repair the disk boot sector, as BIOS is not writable and does not need to be repaired when there are no issues;(2) UEFI/GPT systems: Use tools like efibootmgr / bcdedit to rebuild the EFI files and update the NVRAM boot entries.(3) Given the infinite creativity of humans, there are also cases of using BIOS to boot GPT and UEFI to boot MBR, but this is beyond the scope of this article.