Deciding on Different Boot Solutions
Fixing Grub on an encrypted disc can be similar to fixing unencrypted Linux installation or it can be quite different.
It’s important that you understand your exact situation first and it mainly comes down to:
- Mount points
- Encryption
Boot Partition Mount Points
Normally, you will have a structure similar to this:
- /boot : You will see Linux kernel and initramfs right here.
- /boot/grub : You will have grubenv, grub configuration here.
- /boot/efi : You will find the efi bootloader here.
Encryption of Disc or Partitions
It’s common to encrypt only the root partition with cryptsetup and leave the boot partitions unencrypted.
This is useful especially if you are sometimes using other bootloaders or dual-booting with Windows etc. It’s slightly less-secure obviously since your boot partition is unencrypted. But unless you are Ethan Hunt or Edward Snowden or something it should be fine.
Logic of Boot Partition Mounting Points
Understanding both sections is crucial because if you mount your boot partition to only /boot/efi , then grub-install will install EFI bootloader there but the rest will be on /boot directory which is a directory on the encrypted root partition.
If you however, mount boot partition to /boot now the grub installation as well as /boot/efi and linux kernel (plus initramfs) will all be on the unencrypted /boot directory.
A mini-test to understand this is, if you are using the /boot dir for boot partition and if you unmount boot partition local /boot directory of the root partition should be completely empty, Otherwise when you unmount the boot partition only /boot/efi would be empty.
Implications of it all
Hopefully it’s clear that we have two scenarios where Grub can freely read all boot files including kernel versus grub can only read EFI bootloader entry and then it would need encryption password to proceed.
Solutions will be different and the former is less complicated and generally convenient while the latter is more secure. Rest assure, in both cases you can save your operating system even if you completely wipe the boot partition.
Re-generating vmlinuz linux kernel and initramfs files.
If you have accidentally deleted your boot directory’s content also, this is actually an easy fix to replace those files.
First chroot into your root partition using a live USB.
In a Linux computer, typically crucial system files such as initramfs, vimuz-linux kernel and efi and grub folders reside inside the boot directory.
Although these are seriously important system files for a computer, they can actually be restored quite conveniently in most cases.
To generate linux kernel and initramfs files simply run this command:
mkinitcpio -PThis will recreate the files named:
- initramfs-linux-fallback.img
- initramfs-linux.img
- intel-ucode.img
- vmlinuz-linux
under the boot directory.
Solutions for Luks encrypted Root Partition only
Most tutorials will suggest following mount points when installing grub.
sudo mount /dev/sdXY /mnt/boot/efi
sudo mount /dev/sdXX /mntHowever, when you are dealing with a luks encrypted root partition, you will want to mount as below:
(See below for more explanation on this.)
sudo mount /dev/sdXY /mnt/boot
sudo mount /dev/sdXX /mntThis is mainly because we don’t want grub and linux kernel will be installed inside /boot directory and we don’t want them to fall outside the unencrypted EFI partition. If they are installed on the root partition, they won’t be accessible during startup boot loading period as they will be on the encrypted partition.
Luks encrypted systems are in most cases
- sda
- sda1 (Buffer for Legacy)
- sda2 (EFI Partition)
- sda3 (Luks Encrypted Root)
In 90%+ of the cases users don’t have to encrypt the boot partitions as there won’t be any personal data in there (there can still be security implications).
This means uncommenting #GRUB_ENABLE_CRYPTODISK=y is usually not necessary.
If you are encrypting the whole disk including the boot partitions however, this is also possible and you will need to uncomment. see below section.
When grub configuration goes wrong on an encrypted setup users often get errors like below while attempting to reinstall grub:
grub-install: error: attempt to install to encrypted disk without cryptodisk enabled. Set `GRUB_ENABLE_CRYPTODISK=1′ in file `/etc/default/grub’..
Don’t do this:
#GRUB_ENABLE_CRYPTODISK=y!! Leave this option commented unless your EFI boot partition is encrypted (luks). !!
However, let’s reiterate this, unless your boot partition is encrypted as well as your root partition, you don’t need to enable crypto disk in grub configuration. But why the error then?
The answer is, in most cases it will be a mounting issue. Let’s clarify a couple things to solve this issue forever.
Normally root partition is mounted to /mnt while EFI partition is mounted to /boot/efi
In a luks encrypted system however, it makes more sense to mount EFI partition (for example /dev/sda2) into /boot instead of /boot/efi.
This is because while you install grub to /boot/efi, linux kernel and initramfs will remain in /boot directory.and if the /boot resides under encrypted /mnt such as /mnt/boot, this means kernel and initramfs files will fall outside the unencrypted EFI partition and they will be inside the luks partition. In this case grub-install will think you are trying to install grub to an encrypted disc and suggest crypto disc to be enable although you actually don’t need that if you mount properly.
Long story short,
mount EFI partition to /mnt/boot
create /mnt/boot/efi
install grub to efi directory with –efi-directory=/boot/efi argument
## !! ATTENTION: change sdaX as need, values below are hypothetical !!
# Assuming sda3 is encrypted root partition and sda2 is unencrypted EFI partition.
sudo cryptsetup luksOpen /dev/sda3 cryptdisc
mount /dev/mapper/cryptdisc /mnt
mount /dev/sda2 /mnt/boot
Chroot into /mnt and install and configure grub on right mount points as discussed above.
Make sure /etc/fstab has the correct mount points as well for after the reboot.
arch-chroot /mnt
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg
Now, if you need to regenerate vimuz-linux kernel and initramfs files, you can simply run the command below and they will be created inside the boot directory which is unencrypted as EFI partition is mounted there.
You might have to install linux kernel if it’s deleted.
sudo pacman -S linux
mkinitcpio uses linux kernel to create initramfs or initial ram disk file system.
mkinitcpio -P
After running mkinitcpio, run grub-mkconfig as above again and then you can unmount everything with umount -a and reboot.
-P flag signifies all presets which can be found inside the /.etc/mkinitcpio.d/linux.preset file as below:
# mkinitcpio preset file for the 'linux' package
#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"
ALL_microcode=(/boot/*-ucode.img)
PRESETS=('default' 'fallback')
#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-linux.img"
#default_uki="/efi/EFI/Linux/arch-linux.efi"
#default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp"
#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/initramfs-linux-fallback.img"
#fallback_uki="/efi/EFI/Linux/arch-linux-fallback.efi"
fallback_options="-S autodetect"
Solutions for Luks encrypted Root & Boot Partitions
In this case solutions won’t be too different to above. Edit /etc/default/grub file to uncomment below command. This will allow Grub to recognize and boot from Encrypted boot directory/partition. Obviously this will cause you to get password prompt twice:
- Once before boot
- Once before system is mounted
#GRUB_ENABLE_CRYPTODISK=yIf you enable cryptodisk but you’re actually not using encrypted boot partition you might get an error like below:
Error : grub-install: error: attempt to install to encrypted disk without cryptodisk enabled. Set `GRUB_ENABLE_CRYPTODISK=1′ in file `/etc/default/grub’..
Solution is either, don’t use GRUB_ENABLE_CRYPTODISK=y or actually encrypt your boot partition. If it’s a bit confusing make sure to understand the mount points at the beginning of this tutorial.
Uncommenting the line above only instructs Grub about encrypted boot. It doesn’t solve all your boot problems. If something is wrong with your grub installation or configuration, you will still have errors like this one:
Enter passphrase for (hd,gpt):
Error : Invalid passphrase.
Error : access denied.
Error : no such cryptodisk found.
Error : disk ‘cryptouuid/……’ not found.
Entering rescue mode…
grub rescue>
To solve this, you can make sure grub-install is properly executed for /boot/efi and contains valid linux kernel and initramfs files along with grub folder.
If somehow you managed to corrupt or remove the Encryption Headers in the beginning of the encrypted disc, in most cases there is not much to do to save that system. Getting the boot errors and invalid passphare above doesn’t necessarily mean this is the case and just fixing the boot issues will resolve all errors. Unless again, if encryption data is corrupted. You can read more about LUKS Encryption below:
LUKS Encryption Headers
LUKS (Linux Unified Key Setup) is a disk encryption specification used in Linux-based systems. It provides a standard format for storing encrypted data on disk, allowing for secure storage of sensitive information.
In the context of LUKS, the “LUKS encryption header” refers to a specific data structure that contains important information about the encrypted disk or partition. This header is located at the beginning of the encrypted device and holds essential metadata needed to access and decrypt the data.
The LUKS encryption header includes the following information:
Key Slots: The header contains several key slots, which store encryption keys used to decrypt the data. Each key slot can hold a passphrase or a key file that grants access to the encrypted disk. Multiple key slots allow for the use of different passphrases or multiple users with distinct encryption keys.
Cipher and Encryption Parameters: The header stores information about the encryption algorithm, key size, and other parameters used for the encryption process. These parameters determine the strength of the encryption and the algorithm used to protect the data.
UUID and Label: The LUKS header may also include a Universally Unique Identifier (UUID) and a user-defined label. The UUID uniquely identifies the encrypted device, while the label provides a human-readable identifier for easier identification and management.
Anti-Forensic Information: LUKS supports anti-forensic features to mitigate attacks aimed at revealing information about the encrypted data. The header may include details such as the number of times the device has been opened or various parameters related to anti-forensic measures.
The LUKS encryption header is crucial for the proper functioning of the encrypted disk or partition. It contains the necessary information for the system to validate and access the encrypted data. During the boot process or when mounting an encrypted device, the system reads and verifies the header, prompts for a passphrase or key, and uses the provided information to decrypt the data.
It’s important to ensure the security and integrity of the LUKS encryption header. Any damage or corruption to the header could lead to the loss of data or difficulties in accessing the encrypted device. Therefore, it is recommended to keep backup copies of the LUKS header and store them securely to ensure the ability to recover the encrypted data if needed.
Flow of a Boot Process in Linux Systems
GRUB, or the GRand Unified Bootloader, is a commonly used bootloader in Linux systems. Its main function is to load and start the operating system. While the Linux kernel and initramfs files are essential components of the operating system, they need a bootloader like GRUB to be loaded into memory and executed.
Here’s a brief overview of how GRUB functions when Linux is installed on a machine:
Powering on the machine: When you power on a computer, the BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface) firmware initiates the boot process.
GRUB installation: GRUB is typically installed in the Master Boot Record (MBR) or the EFI system partition, depending on the boot mode (legacy or UEFI).
GRUB initialization: Once the firmware locates and loads GRUB, GRUB initializes itself and presents the user with a boot menu (if configured).
Kernel and initramfs loading: From the boot menu, the user selects the desired Linux kernel and initramfs. GRUB then reads the necessary files from the configured boot partition.
Passing control to the kernel: GRUB transfers control to the loaded Linux kernel by passing the necessary parameters and memory location details.
Kernel execution: The Linux kernel takes control and starts initializing the hardware, loading drivers, and setting up the essential components of the operating system.
Initramfs usage: The initramfs (initial RAM file system) is a temporary root file system that the kernel mounts early during the boot process. It contains essential drivers and utilities required to mount the actual root file system. The kernel uses initramfs to load the necessary modules and prepare the system for the handover to the real root file system.
