Notes on installing Linux Mint 22.2 (full disk encryption)
Introduction
These are my notes to self for the next time I install a Linux system. As if I read my previous posts before attempting.
So I installed Linux Mint 22.2 (kernel 6.14.0-29) on a Lenovo V14 G4 IRU laptop. With Cinnamon, of course, not that it’s relevant.
All that I wanted was a full-disk encryption, but being allowed to choose the setup of the partitions explicitly, and not let the installation wizard make the choices for me. In particular, I wanted a swap partition with the size I choose, and even more important: Almost all disk space in a /storage mount, so that one can fill the hard disk with junk without risking a system failure because root partition is full.
Cutting the cake
/boot/efi is where the BIOS reads from. It’s natural to put it as the first partition, and it can be very small (even 1 MB can be enough in some cases, but let’s not push it like I eventually did). But if you make it really small, it’s a FAT16 partition, not FAT32, and that’s OK. Don’t force it into FAT32, because the system won’t boot with it if it has less clusters than required.
So it goes like this:
- Create three partitions:
- First one for /boot/efi (e.g. nvme0n1p1), 10 MB. This must be FAT32 or FAT16 (the latter for 10MB). Note that 10MB is a bit too small, because the BIOS won’t have room for its own backup this way.
- Second one for /boot, will contain initramfs images, so ~500 MB. Any filesystem that GRUB can read (so ext4 is definitely OK)
- Third partition for LUKS
- In the LUKS partition, create an LVM with partitions for / (100G) and swap. The rest is for /storage.
It’s somewhat confusing that /boot/efi is a subdirectory of /boot, but that’s the way it is.
Running the installation wizard
- Unlock the encrypted partition, if it’s not already (e.g. with the “Disks” GUI utility). This requires giving the passphrase, of course.
- Double-click the “Install Linux Mint” icon on the desktop.
- When reaching the “Installation type”, pick “Something else”.
- Set the following mount points:
- Set the small FAT partition (nvme0n1p1 in my case) as “EFI System Partition”
- /boot on the partition allocated for that (non-encrypted partition, possibly ext4).
- / on the relevant LVM partition inside the encrypted block
- Set the swap partition
- Set the “Device for boot loader installation” to the one allocated for “EFI System Partition” (nvme0n1p1) in my case. One may wonder why this isn’t done automatically. Note that it’s the first partition (/dev/nvme0n1p1) and not the entire disk (/dev/nvme0n1).
- Don’t do anything with the planned /storage partition. As I don’t want to assign it with a mounting point, handle it after the installation is done.
If the installation ends with a failure to install GRUB, run “journalctl” on a terminal window and look for error messages from the grub installer. Don’t ask ChatGPT to help you with solving any issues, and don’t ask me why I know it’s a bad idea.
When I insisted on FAT32
Sometimes I’m too much of a control freak, and when the Disks utility formatted the EFI partition into FAT16, I thought, oh no, it should be FAT32, what if the BIOS won’t play ball?
Well, that was silly of me, and also silly to ignore the warning about a FAT32 filesystem with just 10 MB having too few clusters.
So even though the installer wizard finished successfully, there was no option to boot from the disk. Secure boot was disabled, of course. And yet, there was no suitable option in the BIOS’ boot menu. There was a “UEFI” option there, which is always in black (not possible to select), but that doesn’t seem to be relevant.
Following the warm advice of ChatGPT, I added an entry while in Live USB mode:
# efibootmgr -c -d /dev/nvme0n1p1 -p 1 -L "Linux Mint" -l '\EFI\ubuntu\grubx64.efi' BootCurrent: 0000 Timeout: 0 seconds BootOrder: 0003,2001,2002,2003 Boot0000* EFI USB Device (SanDisk Cruzer Blade) UsbWwid(781,5567,0,4C53011006040812233)/CDROM(1,0x2104,0xa000)RC Boot0001* EFI PXE 0 for IPv4 (AA-BB-CC-DD-EE-FF) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/MAC(aabbccddeeff,0)/IPv4(0.0.0.00.0.0.0,0,0)RC Boot0002* EFI PXE 0 for IPv6 (AA-BB-CC-DD-EE-FF) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/MAC(aabbccddeeff,0)/IPv6([::]:<->[::]:,0,0)RC Boot2001* EFI USB Device RC Boot2002* EFI DVD/CDROM RC Boot2003* EFI Network RC Boot0003* Linux Mint HD(1,GPT,12345678-aaaa-bbbb-cccc-dddddddddddd,0x800,0x5000)/File(\EFI\ubuntu\grubx64.efi)
(some identifying numbers replaced trivially)
Cute, heh? But it made no difference. After rebooting with a Live USB again:
# efibootmgr BootCurrent: 0000 Timeout: 0 seconds BootOrder: 2001,2002,2003 Boot0000* EFI USB Device (SanDisk Cruzer Blade) UsbWwid(781,5567,0,4C53011006040812233)/CDROM(1,0x2104,0xa000)RC Boot0001* EFI PXE 0 for IPv4 (AA-BB-CC-DD-EE-FF) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/MAC(aabbccddeeff,0)/IPv4(0.0.0.00.0.0.0,0,0)RC Boot0002* EFI PXE 0 for IPv6 (AA-BB-CC-DD-EE-FF) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/MAC(aabbccddeeff,0)/IPv6([::]:<->[::]:,0,0)RC Boot2001* EFI USB Device RC Boot2002* EFI DVD/CDROM RC Boot2003* EFI Network RC
So the entry was gone.
I changed the EFI partition to FAT16, ran through the installation all the way again. And immediately after the installation was done (before booting to start from disk for the first time):
# efibootmgr
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0003,2001,2002,2003
Boot0000* EFI USB Device (SanDisk Cruzer Blade) UsbWwid(781,5567,0,4C53011006040812233)/CDROM(1,0x2104,0xa000)RC
Boot0001* EFI PXE 0 for IPv4 (AA-BB-CC-DD-EE-FF) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/MAC(aabbccddeeff,0)/IPv4(0.0.0.00.0.0.0,0,0)RC
Boot0002* EFI PXE 0 for IPv6 (AA-BB-CC-DD-EE-FF) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/MAC(aabbccddeeff,0)/IPv6([::]:<->[::]:,0,0)RC
Boot0003* Ubuntu HD(1,GPT,12345678-aaaa-bbbb-cccc-dddddddddddd,0x800,0x5000)/File(\EFI\ubuntu\shimx64.efi)
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network RC
This time, when the laptop went on, the BIOS came up with a “Please don’t power off while completing system update”. What it actually did was to write its own backup file into the EFI partition, which appears as /boot/efi/BackupSbb.bin. Actually, it doesn’t seem like it was successful, as the space in the partition ran out. So I deleted this file and turned off the “BIOS Self-Healing” option in the BIOS’ configuration (it will be much worse if it attempts to self-heal on a faulty backup file).
At this point, there was an “ubuntu” entry in the list of boot options in BIOS’ boot menu (Not “Ubuntu”, but “ubuntu”, probably referring to the directory and not the name). And the black “UEFI” option remained in the option list, not possible to choose. So this is why I don’t think it’s relevant.
Asking for a passphrase is too much to ask?
Having reached this far, I got a nice Linux Mint logo on the screen, however nothing happened, and then I got thrown into a initramfs rescue shell. In other words, no attempt to unlock the encrypted partition.
So I ran the live USB again, unlocked the root partition and mounted it as /mnt/root/.
Then, as root (sudo su), bind-mounted the essential directories into the root filesystem:
# for d in /dev /dev/pts /proc /sys /run; do mount --bind $d /mnt/root/$d ; done
And then chrooted into it.
# chroot /mnt/root
Of course, there was no /etc/crypttab, so no wonder that the installation didn’t take unlocking the encrypted partition into account.
So I followed my own instruction from a previous post. First, mount /boot and /boot/efi with
# mount -a
and then check for the UUID of the encrypted partition:
# cryptsetup luksUUID /dev/nvme0n1p2 11223344-5566-7788-99aa-bbccddeeff00
and then add /etc/crypttab reading
luks-11223344-5566-7788-99aa-bbccddeeff00 UUID=11223344-5566-7788-99aa-bbccddeeff00 none luks
Note that the luks-{UUID} part is as the name of the partition as it appears in /dev/mapper. In this case, this was what the Disks GUI utility chose. Had I done this with command line, I could have chosen a shorter name. But who cares.
And finally, edit /etc/default/grub for your preferences, update initramfs and GRUB, exactly as already mentioned in that post:
# update-initramfs -u # update-grub # grub-install
It was really exactly the same as the previous post. And then reboot, and all was finally fine.
And by the way, the initrd file is 77 MB. Running update-initramfs again didn’t make it smaller. Not a big deal with a flash disk, anyhow.
But GRUB can open LUKS too!
GRUB has cryptodisk and luks modules which can open an encrypted partition, so in principle it can read the kernel from an encrypted root partition. However there is no mechanism I’m aware of to pass over the unlocked encrypted partition to the kernel, so it would be necessary to supply the passphrase twice when booting.
This is why I went for two partitions for booting. I guess this still is the only sane way.