Bootloader Installation and Troubleshooting GRUB Installation Failed on /dev/sda

1. Introduction

Many older and more specialized Linux distributions have primitive installation mechanics that either have no front end at all or use a terminal user interface (TUI). Installing a current major distribution is usually a much more comfortable experience, involving not only a full-fledged graphical user interface (GUI) but also many conveniences in the form of automated steps. Still, some automation may cause issues in the case of edge cases.

In this tutorial, we talk about storage medium detection and the bootloader installation during the setup of some Linux distributions. First, we briefly refresh our knowledge about bootloaders. After that, we turn to bootloader installation in general. Finally, we explore a common error with one of the most widely used bootloaders for Linux.

We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. It should work in most POSIX-compliant environments unless otherwise specified.

2. Bootloaders

After performing the installation or inserting the medium of any operating system (OS), the machine BIOS or UEFI should be aware of the path to its kernel and how to run it. This is the role of a bootloader:

• scan for and enumerate bootable filesystems and partitions
• present a list of options when starting the machine
• provide a way to add options when booting a particular kernel or OS

Notably, most bootloaders support many operating systems. On the other hand, some operating systems only have a single native boot system. However, Linux supports and is supported by many bootloaders.

Still, perhaps the most widely used one is the GRand Unified Bootloader (GRUB). In fact, although systemd can also be used as the bootloader, GRUB is still the main or only option in most major Linux distribution installation media.

3. Bootloader Installation

During most Linux installation procedures, there is a step for setting up a bootloader. It’s optional, as our system might already have one, but there is usually at least a single option just in case.

As already stated, due to its ubiquity, GRUB is part of most installers and already deployed Linux systems. In fact, many automatic actions may run during the installation of bootloaders:

• detect MBR or GTP setup
• detect boot medium or media
• detect boot partition
• detect filesystems

Despite this, there are cases when the automated installer may not properly detect the correct drive, partition, or filesystem to install the bootloader on.

4. GRUB Installation Failed on /dev/sda

When installing a bootloader like GRUB, the system attempts to detect two main conditions:

• where we want to install
• which storage part or medium we aim to make bootable

Notably, while the second decision might look more important, the first one can be fatal.

4.1. Master Boot Record (MBR)

Usually, the first sector of a storage medium is called a Master Boot Record (MBR) and is reserved for the partition table. Yet, we can also install a bootloader like GRUB in the MBR, thereby overwriting any other bootloader.

Still, if GRUB hasn’t properly detected all bootable parts of the system, we might end up with a new bootloader that doesn’t recognize any operating system before the one it was installed with.

Because of this, there are systems that leave the original bootloader intact, but add an entry to it for a new partition. Then, we ensure GRUB or a new bootloader is installed in the first sector of that partition. This way, we ensure that at least our original OS is bootable.

4.2. Incorrect Medium

Since OS installation usually involves an external medium like a compact disk (CD) or a USB flash drive, that might be present on the system during bootloader installation.

This fact can present challenges with the proper medium detection. For example, let’s assume that, when installing Linux, we have three drives available:

1. /dev/sda: removable USB flash drive with OS installer
2. /dev/sdb: first fixed storage medium, HDD, where we have another OS
3. /dev/sdc: second fixed storage medium, SSD, where we want to install Linux

At the end of the setup, the installer should decide where to install the bootloader. Often, the sane default action is to pick the first fixed drive. In this case, that would be /dev/sdb, which might be a mistake, since that storage medium probably already has a bootloader for the current OS there.

Critically, newer portable drives have controllers that are similar or equivalent to the ones for fixed storage, further compounding the problem. In that case, we might end up with two problems:

• non-bootable USB flash drive contents
• non-bootable Linux installation (bootloader on USB flash drive)

To avoid such issues, we usually set the local drive or partition that we install Linux on to hold the bootloader. If needed, we then chain the bootloaders, so the main one loads any secondary ones.

5. Summary

In this article, we talked about bootloaders, how they are installed, and three main things to watch out for when installing:

• target container type (drive or partition)
• target storage medium
• bootable system detection

In conclusion, although many of the steps to install a Linux system are now automated, it’s still part of best practices to ensure each step has detected the proper context and actions before proceeding.