When the BIOS fails to detect a bootloader, the system typically halts with a "No bootable device" error because the Unified Extensible Firmware Interface (UEFI) cannot locate the EFI System Partition or the specific bootloader file within it. This issue is most common in Arch Linux installations where the grub-install command was executed incorrectly, the partition flags were not set properly, or Secure Boot is actively blocking unsigned binaries.
Verify EFI System Partition Mounting
The foundation of any UEFI boot process is the correct mounting and identification of the EFI System Partition (ESP). Before attempting to reinstall the bootloader, you must ensure that your ESP is mounted at the standard location, which is usually/boot/efi or /boot, depending on your specific configuration. If this partition is missing or empty, the BIOS will have no path to follow during the POST sequence.
Open a terminal and use the lsblk command to list all block devices. Look for a partition marked as efi or boot with a FAT32 filesystem. It should be small, typically between 100MB and 512MB. If you are working from a live environment, mount your root partition and then the ESP to verify accessibility:
mount /dev/sdXN /mnt
mount /dev/sdYM /mnt/boot/efisdXN with your root partition and sdYM with your EFI partition. Once mounted, check if the directory /mnt/boot/efi/EFI exists. If this directory is absent, your partition structure is likely incorrect, or the ESP was not formatted correctly during installation. You can also run fdisk -l /dev/sdX to inspect partition types; the EFI partition must have the type code EF00.
Correct GRUB Installation Paths
A frequent cause of BIOS recognition failure is an incorrect target directory during thegrub-install execution. The previous error regarding the /arch/ path suggests a misunderstanding of the directory hierarchy. In a standard Arch Linux setup, GRUB files reside in /boot/efi/EFI/grub/, not in a custom /arch/ folder unless you have explicitly created one, which is non-standard and often missed by firmware.
To repair this, enter your chroot environment using arch-chroot /mnt. Ensure your EFI partition is mounted inside the chroot at /boot/efi. Then, execute the installation command with the correct target architecture and directory:
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB/boot/efi/EFI/grub/. The --bootloader-id flag creates a folder named GRUB inside the EFI directory, which some BIOS implementations require to identify the entry. After running this, verify that the file /boot/efi/EFI/grub/grubx64.efi exists. If it does, the binary is in the correct location for the UEFI firmware to load.
Check Partition Flags and Secure Boot
Even with correct files, the BIOS may ignore the bootloader if the partition lacks the necessary boot flags or if security features are misconfigured. The EFI System Partition must have theboot flag set. You can verify and set this using parted or fdisk. For example, in fdisk, you would use the t command to change the type to EF00. Without this flag, some older or stricter motherboards will not list the drive in the boot order menu.
Additionally, check your BIOS settings for Secure Boot. While modern Linux distributions support Secure Boot, manual Arch installs often do not sign the GRUB binary by default. If Secure Boot is enabled, the BIOS will reject the unsigned grubx64.efi file. Temporarily disable Secure Boot in the BIOS settings to see if the bootloader becomes visible. If disabling it resolves the issue, you either need to enroll MOK keys or disable Secure Boot permanently if you prefer not to manage signatures.
For more detailed guidance on navigating these firmware settings, you might find our guide on understanding BIOS boot options helpful. It covers how different manufacturers label these options and how to navigate the UEFI shell if necessary.
Regenerate the GRUB Configuration
After ensuring the binary is in the right place, you must generate the main configuration file that lists your operating systems. Rungrub-mkconfig -o /boot/efi/EFI/grub/grub.cfg. This step is critical because even if the BIOS finds the bootloader, it needs a valid grub.cfg to know what kernel to load. If this file is missing or corrupted, the screen may go black or display a GRUB prompt immediately after selection.
You can also manually add an entry to your BIOS boot menu using tools like efibootmgr. Run efibootmgr -v to see current entries. If GRUB is not listed, you can force an entry creation:
efibootmgr -c -d /dev/sdX -p Y -L "GRUB" -l "\EFI\grub\grubx64.efi"Inspect Hardware Compatibility
In rare cases, the issue lies with hardware compatibility rather than software configuration. Some older motherboards have bugs with large hard drives or specific NVMe controllers. If you are using an NVMe drive, ensure your BIOS is updated to the latest version, as early UEFI implementations had poor NVMe support. Additionally, try connecting the drive to a different SATA port if applicable, or test with a USB boot stick to isolate whether the motherboard can read the storage controller at all. If you are dual-booting with Windows, refer to articles on managing mixed bootloader settings to ensure Windows Fast Startup is disabled, as it can lock partitions and prevent Linux from writing the necessary boot files correctly.Frequently Asked Questions
Why does my BIOS show the drive but not the OS?
This indicates the firmware detects the physical storage but cannot parse the partition table or locate the EFI executable. Ensure the EFI System Partition is formatted as FAT32 and has the correct boot flag set. Also, verify that the grubx64.efi file exists in the expected directory structure.
Can I fix this without reinstalling Arch Linux?
Yes, you can repair the bootloader from a Live USB. Boot into the live environment, mount your partitions, chroot into your system, and re-run grub-install and grub-mkconfig. This restores the boot files without touching your existing data or user configuration.
What if Secure Boot is required by my manufacturer?
If Secure Boot is mandatory, you must sign your GRUB binary or enroll Microsoft's KEK and DB keys in your BIOS. Alternatively, install the shim package, which provides a signed bootloader that can chainload unsigned GRUB binaries, allowing you to keep Secure Boot enabled while booting Linux.
How do I remove a bad boot entry from BIOS?
You can use the efibootmgr tool within your chroot or live environment. Use the -B flag followed by the boot number (e.g., efibootmgr -b 0001 -B) to delete the specific entry. Always double-check the output of efibootmgr -v before deleting to avoid removing a valid entry.
Is NVMe support different from SATA for bootloaders?
The bootloader installation process is identical regardless of the drive interface, as GRUB abstracts the hardware differences. However, NVMe drives may require specific kernel modules loaded earlier in the boot process. Ensure your initramfs includes the NVMe drivers by regenerating it with mkinitcpio -P if the system fails to find the root filesystem after GRUB loads.