GRUB vs GRUB2: Which Should I Use?

All operating systems need something called a bootloader that tells the computer how to start up. No matter the computer type, all systems boot in functionally the same way from a high-level perspective. First, the BIOS or UEFI is loaded and enumerates the hardware installed in that computer. Then that BIOS/UEFI hands-off responsibilities to the boot loader to start the OS. In the Linux world, that bootloader is typically Grub or its counterpart, Grub2.

A Little Grub History

The first version of Grub was initially written by Erich Boleyn. It was developed in conjunction with the Free Software Foundation as a method for loading the GNU operating system. Grub became an official software package for the GNU Project in 1999.

In 2002, work for Grub2 started. It originally went by the name PUPA. Grub2 was designed from the ground-up as a complete rewrite of the original Grub software package to handle more modern requirements. Grub2 has since become the primary bootloader for most major distributions of Linux.

How Bootloaders Work

To fully understand the difference between Grub and Grub2, we need to understand how bootloaders work. Bootloaders are installed in the master boot record (MBR) for the computer. The MBR is typically stored in the first enumerated primary drive in the system.

That MBR is small and typically consists of four partitions at 64bytes in size. That boot record would traditionally hold all the information that tells the computer where and how to access the files to load an operating system (OS). Each record must be stored in that MBR for the computer to boot properly, and it must be updated manually as system conditions change. For example, a hard drive is swapped or moved, or a different OS is installed.

Grub was created to solve that issue. Instead of the MBR pointing directly to the resources required to load the OS, those MBR records instead point to the files needed to load Grub. From there, Grub then references the resources needed to load the OS. This bypassed the memory limitations of the traditional MBR bootloader which allowed things like graphical boot loaders and a multi-OS environment.

Grub still had limitations, though. Hence why Grub2 was developed. We'll go into more details with that below.

The Differences Between Grub and Grub2

Grub and Grub2 have many similarities. In fact, often the two aren't discernable from the end user’s perspective when the OS loads. Both are capable of handling the boot process for multiple OSes, both can auto-load OSes, and both can have a simplified command-line environment-like interface for choosing which OS to boot. But those commonalities are mostly high-level and end there.

How Grub and Grub2 Reference Storage Devices

First, the original version of Grub references storage devices by their hardware address. For example, an SSD block storage device is typically referenced as SDA1, SDA2, and so on in Linux. This can cause issues. For example, if a drive is cloned due to hardware failure or other issues, and the new drive is installed in the system, that hardware designation can change. Likewise, if storage devices are simply moved to different ports during maintenance, that can change the hardware designation as well.

If the hardware designation changes for a storage device, the Grub configuration files need to be edited. Otherwise, Grub will not be able to locate the resources needed to boot an OS.

On the other hand, Grub2 references devices by their UUID. This can improve the stability of the bootloader. It also makes the boot loader more fault-tolerant since it can still reference the resources needed even if the hardware designation changes.

How Configuration Files Are Generated

The legacy version of Grub stores its configuration in multiple files. These files need to be written by hand. While this can reduce the file size of those configuration files, it also introduces more complexity.

Let's touch on those file sizes quickly and why that's an issue. While the MBR is still used for both Grub and Grub2 to an extent, the way it interacts with both is different. After the MBR is referenced by the computer BIOS/UEFI, the MBR records reference the preceding bytes after the MBR on the storage device for further instructions. That space is also limited.

This is the space where the legacy version of Grub would live, but that can present issues with certain file systems, partition sizes, and storage device types. Though the original version of Grub is small enough to live in this space, it's also severely limited with what hardware configurations and file systems it can support. Grub2 solves those issues but at the cost of file size. So, instead of referencing Grub directly, that extra space holds files that are yet another pointer to the Grub2 bootloader stored elsewhere. We should note that these file size differences are incredibly small, but they are large enough to make a difference with where the bootloader is stored and how it must be referenced.

With that understanding, Grub2 stores its configuration in a single file. Likewise, that file should never be changed by hand. Instead, the Grub2 configuration files are automatically generated by other configuration files in the OS. While this solves compatibility issues while decreasing complexity, it also makes Grub2 larger than the legacy version of Grub.

The Difference Of Compatibility With Grub vs. Grub2

Given that the legacy version of Grub is more limited, what do those limitations consist of?

The answer is simple. Because Grub is limited to how and where it can be referenced and loaded during boot, that means it cannot support different types of file systems. Certain types of RAID environments or LVM storage aren't compatible with Grub because those configurations can't be stored in the partition storage area of the drive that the MBR references after loading.

On the other hand, because Grub2 is capable of referencing file locations for the OS in a different way than Grub, Grub2 can support a wide range of RAID environments, LVM, as well as newer filesystems like ReiserFS. This offers system administrators the ability to use newer PC architectures and file systems that support newer journaling, snapshot, and other features.

Grub2 also supports newer UEFI systems and non-x86-based PC architectures. If systems administrators need to install Linux on an ARM device, a PowerPC device, or a device that utilizes UEFI instead of the older-fashioned BIOS, they must use Grub2 – full stop. The legacy version of Grub cannot support these architectures.

Other Differences Between Grub vs. Grub2

We need to touch on how configuration files are created. While the legacy version of Grub requires that its config files are manually created, the config files for Grub2 are created automatically by a scripting process. Grub2 includes basic scripting which means that it can dynamically collect OS and hardware resource information. That makes Grub2 more resilient in the long run for maintainability.

Grub2 is also modular. During the development process for Grub2, the core x86-based code was abstracted from the bootloader and pushed to a modular system instead. This is also the same mechanism that allows Grub2 to expand functionality and support more filesystems and system architectures that the legacy version of Grub cannot support.

Grub2 is fully theme-able. Though this is an afterthought for most end-users, distributions like Ubuntu and Red Hat use this feature to brand their versions of the bootloader. Other systems integrators can take advantage of the theme-able bootloader as well.

One final note. Grub2 offers features for live boot environments and boots ISO images. This is the reason we can run Linux directly from a DVD.

Verdict: Should You Use Grub or Grub2?

If you're wondering whether you should use Grub or Grub2, the answer is pretty simple. Use Grub2.

While some Linux distributions, like CentOS or earlier versions of REHL use Grub, the newer versions of REHL, Ubuntu, and other distros have migrated to Grub2. Grub2 has become the default bootloader for most Linux distributions. If you need to run Linux on an IoT device, a device with a non-x86 based architecture, or a device with UEFI instead of a BIOS, or a device that requires secure boot, you must use Grub2 as the legacy version of Grub does not support these use cases.

The fact is that development for the legacy version of Grub has stopped and Grub2 is here to stay.

One Last Thing: Install Windows First

Though both the Windows bootloader and Grub2 support multi-OS environments, if you need to run both Windows and Linux on a single computer with dual-boot capabilities, always install Windows first. Windows has a nasty habit of overwriting the Grub bootloader and will not recognize Linux OSes by default. IT administrators can configure the Windows bootloader to recognize and boot Linux OSes after Windows is installed, but it can be difficult to accomplish and requires extra bootloader configurations.

On the other hand, Grub2 recognizes Windows without a problem. Most Linux distributions will automatically configure the Grub2 bootloader properly when the Linux OS is first installed to include Windows in its OS selection list, though additional configuration will still be needed if you want to load Windows by default with Grub instead of Linux. Those configuration options are far easier to change in Grub than configuring the Windows Bootloader to recognize Linux, though.