Manjaro tutorial: BIOS, UEFI, MBR, GPT, GRUB, SED, LUKS - Feature image

Manjaro tutorial: BIOS, UEFI, MBR, GPT, GRUB, SED, LUKS

by Sven WoltmannJune 1, 2019

In part 1 – Which Linux is best for a Java developer? – I decided to install Manjaro Linux on a Dell XPS 15 9570. In this part, I explain some fundamental basics you should know before starting the installation.

Not that easy after all

After I installed Manjaro as a VM on my Windows computer for testing purposes and skimmed over countless forum posts and how-to's, I realized that the installation is not that easy after all. Desperate users have had over 50 unsuccessful installation attempts. The most frequently asked questions are:

  • What is the difference between BIOS and (U)EFI?
  • Should I install an MBR or a GPT?
  • What is GRUB?
  • Do I need a separate boot partition?
  • How do I encrypt the hard disk during installation? Should I use LUKS or Opal or both? Do I have to encrypt the whole disk or do I have to leave the boot partition unencrypted?
  • What is the right driver for my graphics card, and how do I install and configure it correctly?
  • What do the different GRUB boot options mean, which people usually mention in connection with graphics card drivers? Also, how do I set them?

Most of these questions are answered in the relevant forums, but first and foremost by Linux professionals who formulate the answers in such a way that they do not help a beginner, such as:

"First just getting rid of intel nomodeset i915.modeset=0 then intel and the open source driver for nvidia [nouveau] nomodeset i915.modeset=0 nouveau.modeset=0 then all of it (and try to boot using vesa) nomodeset nvidia.modeset=0 i915.modeset=0 nouveau.modeset=0

Do you get it? Neither do I. That's why I try answering those questions in a way that Linux novices understand them. In the third part, I guide you step by step through the installation of Manjaro on the Dell XPS 15 9570. I only go as far into the details as it is necessary for the installation.


What is the difference between BIOS, UEFI, and EFI?

The BIOS (Basic Input Output System) is responsible for putting the PC into a functional state and then loading the operating system. It was developed in the 70s and has been extended again and again since then. With today's 64-bit systems, however, the expansion options reach their limits.

Therefore, successors were developed: first EFI (Extensible Firmware Interface) and then UEFI (Unified Extensible Firmware Interface) with a focus on 64-bit systems and features like "Secure Boot," which ensures that you can execute only specific, previously signed bootloaders.

All modern motherboards and operating systems support UEFI. Therefore, there is absolutely no reason to install the operating system in BIOS mode (which is emulated by the Compatibility Support Module of the UEFI).


Should I install an MBR or a GPT?

Here we have a similar situation as with BIOS vs. UEFI:

The MBR (Master Boot Record) is a record in the first sector of the hard disk and contains the boot loader (or the first stage of it) and the partition table. The MBR was developed in the 80s, and – like the BIOS – the MBR is reaching its limits more and more. Thus, you can create a maximum of four primary partitions – or three primary partitions and one extended partition, which in turn can contain logical partitions. A partition can have a maximum size of 2 TB.

In the course of UEFI development, the GPT (GUID partition table) was developed as a successor to the MBR. The "G" stands for "GUID" (Globally Unique Identifier) and not for "GNU," so it has nothing to do with Linux.

With the GPT, there is no distinction between primary, extended, and logical partitions, and the number of partitions is not limited (except by available space). The maximum partition size is 18 EB (exabyte), which is 18 million TB or 18 billion GB. I can't imagine how this limit will ever be reached – however, 35 years ago, the MBR developers thought the same thing about the 2 TB limit.

Another advantage of the GPT is that it stores a backup copy of the partition table in the hard disk's final sector.

Like UEFI, GPT is supported by all modern motherboards and operating systems. So the choice should be GPT without a doubt.

What is GRUB?

While UEFI and GPT are used in Windows as well as in Linux, with GRUB ("Grand Unified Bootloader"), we have arrived in the Linux world.

GRUB is, as the name suggests, a bootloader that loads the actual Linux operating system. The bootloader is installed on a separate "EFI System Partition" (ESP), where (U)EFI starts it.

In addition to GRUB, you can also install other boot loaders on this partition, which greatly simplifies the setup of a multiboot system. If, for example, you've previously installed Windows in UEFI mode, then the EFI partition already exists and contains the "Windows Boot Manager." If you now add GRUB, UEFI automatically asks whether it should start Windows or Linux at the next boot process.

For the "EFI System Partition" to be recognized by all operating systems, it is usually formatted with the FAT32 file system.

In Windows 10 disk management, this looks like this:

EFI System Partition (ESP) in Windows 10 Disk Management
EFI System Partition (ESP) in Windows 10 Disk Management

I have tried to illustrate this once again. In the following, you can see an example partitioning of the hard disk:

Hard disk partitions: GPT and EFI system partition (ESP)
Hard disk partitions: GPT and EFI system partition (ESP)

The partitions are not displayed correctly in relation to each other. GPT and ESP are actually much smaller than the other partitions.

  • The GPT refers to the partitions of the hard disk.
  • The ESP (reminder: "EFI System Partition") contains the boot loaders for Windows ("Windows Boot Manager") and Linux ("GRUB") in this example.
  • If the "Windows Boot Manager" is selected when starting the PC, Windows boots from the C:\ partition.
  • If "GRUB" is selected, Linux boots from the Linux root partition.

Do I need a separate Linux boot partition?

On older PCs with BIOS and Master Boot Record, only a part of GRUB (the so-called "stage 1") could be stored on this boot record for space reasons. The major part of the boot loader was in the /boot directory.

As "stage 1" could only access a limited part of the hard disk and could only read a limited number of file systems, the /boot directory had to be located on a separate partition at the beginning of the hard disk and formatted with a file system supported by "stage 1."

For new systems with UEFI and GPT, GRUB easily fits entirely into the EFI partition and can handle pretty much any file system supported by Linux – including software RAIDs, LVMs, and LUKS encrypted file systems.

A separate boot partition is not required on modern systems.

Encrypting the hard disk

If your hard drive contains confidential data, you should completely encrypt it – especially if it is in a laptop that you regularly carry around with you.

There are two types of encryption:

  • Software encryption: under Linux in the form of LUKS ("Linux Unified Key Setup") and under Windows in the form of BitLocker (only included in the professional version)
  • Hardware encryption by "Self-Encrypting Devices" (SEDs).

Software encryption with LUKS

You can easily activate software encryption during the installation of the operating system. To do this, tick the "Encrypt system" checkbox in the "Partitions" step of the Manjaro installation and enter a passphrase (a long password, preferably consisting of several words). The installer takes care of the rest:

Software hard disk encryption with LUKS
Software hard disk encryption with LUKS

Please note: for old systems with BIOS and MBR, a separate /boot partition must be created (see above, "Do I need a separate Linux boot partition?"), which must not be encrypted.

If the data of a running system is to be encrypted, it is a bit more complex. There is no graphical user interface for this. Instead, you have to use the command cryptsetup-reencrypt with the --new option. You can find more details here: Arch Linux – Encrypt an unencrypted filesystem.

Hardware encryption with SEDs and Opal

Almost all modern SSD hard drives support hardware encryption. These devices are called "Self-Encrypting Devices" (SEDs), the "Opal Storage Specification defines the standard for this." This variant has the great advantage that the CPU is not subject to any load.

The encryption works with two keys: a "data encryption key" (DEK), which encrypts the data on the hard disk (orange in the drawing below), and an "authentication key" (AK), which encrypts the "data encryption key" (blue in the drawing):

Hardware hard disk encryption with self encrypting devices (SEDs)
Hardware hard disk encryption with self-encrypting devices (SEDs)

This 2-step system has the advantage that you can change the authentication key at any time. All you have to do is decrypt the data encryption key with the old authentication key and then re-encrypt it with the new authentication key. In the drawing, this would mean that only the lock at the top left has to be replaced.

A change in the data encryption key, on the other hand, would require the entire contents of the hard disk to be encrypted again. This process could take several hours depending on the size of the hard disk. In the drawing, this would mean that all 16 locks on the right side would have to be replaced.

Pre-Boot Authorization Image

To activate encryption (or to enable decryption), a so-called "Pre-Boot Authorization" (PBA) image must be installed on the SSD. The PBA itself is not encrypted. It is installed in the so-called "shadow MBR" - an area of the SSD that is not visible in regular operation. If the SSD is locked, however, the system only sees this "shadow MBR," so that you can only boot the PBA after switching on.

The PBA now asks for the authentication key in the form of a passphrase. Once you enter the passphrase correctly, the SSD hides the shadow MBR and shows the actual data area. A reboot is then initiated, which finally starts the actual operating system.

The disadvantage of hardware encryption is a rather complicated installation. I explain this step by step in the third part of the series, installation of Manjaro Linux on a DELL XPS 15 9570.

Graphics driver

Finally, we come to one of the biggest challenges of all: Which is the right driver for my graphics card? Moreover, how do I configure it correctly? Unfortunately, I can't answer this question in general, since the problems vary from graphics card to graphics card and from one Linux distribution to another, according to my research.

Here, for example, you can find the documentation for the graphics drivers for Arch-Linux:

There is a general VESA driver ("xf86-video-vesa") that should work with all video cards. However, it works only up to a resolution of 1024 x 768 pixels and doesn't provide 2D or 3D hardware acceleration (at least that's how it was in my tests).

GRUB boot options

In the various forum posts, cryptic GRUB boot options appear again and again under the answers. What's that all about?

The boot options can be changed in general, but also directly before booting the operating system and thus affect the boot process. For example, if the kernel does not properly support the graphics card or a faulty graphics card driver has been installed, and the system freezes with a black screen during booting.

Setting the boot options

You can define boot options in the file /etc/default/grub in the following two lines (here at the example of a Manjaro installation in a Hyper-V VM).


List the options, one after the other, separated by spaces. The options placed after GRUB_CMDLINE_LINUX are considered at every start, the options listed under GRUB_CMDLINE_LINUX_DEFAULT only in standard mode, not in recovery mode.

After changes to the file, you have to execute the command update-grub.

To change the boot options for a single boot, press the "E" key (for "edit") when GRUB appears after turning on the computer. In Manjaro it looks like this:

Manjaro GRUB bootloader
Manjaro GRUB bootloader

After pressing "E," the editor appears:

Manjaro GRUB bootloader in "edit" mode
Manjaro GRUB bootloader in "edit" mode

The boot options are listed here in the line beginning with linux after the boot image and can also be changed there directly.

The most important boot options

You should know the following boot options because they appear in forum posts and how-tos:

  • quiet – if you set this option, the kernel messages are not displayed on boot.
  • splash – this option is intended to display a splash screen, but has no effect on my Manjaro test installation.
  • nomodeset – in newer kernels, the graphics mode is activated by the kernel early in the boot process. This option is used primarily to display high-resolution splash screens during the boot process. Since this doesn't work with all video cards, this option can be used to enable video mode only when starting the X Window System.
  • nouveau.modeset=1 (or 0) – enables/disables kernel mode setting (the enabling of video mode by the kernel mentioned above) for Nvidia video cards.
  • i915.modeset=1 (or 0) – enable/disable kernel mode setting for Intel graphics cards.
  • radeon.modeset=1 (or 0) – enable/disable kernel mode setting for AMD Radeon graphics cards.
  • xforcevesa – only VESA mode is used for the graphics display. VESA mode does not require a special graphics driver and should run on all graphics cards – but only in limited resolution and without hardware acceleration.

What I couldn't figure out is which of the "modeset" options have priority. So if, for example, whether "nomodeset" overwrites all other "modeset" options or not.


This article explained the differences between BIOS/MBR and (U)EFI/GPT. On current systems, you should always use the latter combination.

You have learned how GRUB works, how to encrypt your system, what you need boot options for, and how to set them both permanently and for a single boot.

This concludes the preparations for the installation. In the next part, I will describe step by step how to install Manjaro on the DELL XPS 15 9570.

Have I explained things clearly? I'm looking forward to your feedback, your questions and – if a Linux professional reads along – also about hints if something is not 100 percent correct at any point.

If you liked the article, I would be delighted if you share it via one of the following share buttons.

Free Bonus:

Big O Cheat Sheet

[7 Time Complexity Classes on 1 Page]

Use this 1-page PDF cheat sheet as a reference to quickly look up the seven most important time complexity classes (with descriptions and examples).

You get access to this PDF by signing up to my newsletter. I won't send any spam, and you can opt out at any time.
Invalid email address
Sven Woltmann
About the author
I'm a freelance software developer with more than two decades of experience in scalable Java enterprise applications. My focus is on optimizing complex algorithms and on advanced topics such as concurrency, the Java memory model, and garbage collection. Here on, I want to help you become a better Java programmer. Read more about me here.

Leave a Reply

Your email address will not be published. Required fields are marked *

You might also like the following articles