Can I rearrange my encrypted disk to boot faster?

Hi all,

When installing EndeavourOS I selected BTRFS, a swap partition for hibernate, and also turned on the encryption feature. This created two LUKS partitions: one is the root partition and the other one is my swap partition.

Unfortunately this is extremely slow at startup.

Looking into this, I’ve read that the problem may be GRUB: apparently it has very slow code for decoding (no AVX extensions) and given that EndeavourOS encrypts the entire disk it relies on GRUB to do this.

Apparently if you create a separate /boot partition that is not encrypted, you can load the kernel quickly and then leave it to Linux to decrypt the root partition once it is loaded (which should be significantly faster).

Is this theory correct?

If yes, how do I resize my LUKS partition to create a separate /boot? I suppose I can boot into the live environment and use gparted to do the resize and create a separate partition, but once that is done how do I change my system to mount it into /boot? Do I copy the contents from my existing /boot folder, mount the new partition to /boot and then re-run grub? Is that sane?

can you boot on US iso ,
open a terminal & borwser on this topic and provide

inxi -Fza


I wouldn’t bother with copying. It should be as simple as:

  • Creating the partition and formatting it as ext4
  • Adding the new partition in /etc/fstab
  • Testing the /etc/fstab mount
  • sudo mkdir /boot/efi
  • sudo mount /boot/efi
  • re-installing your ucode package(s) using pacman
  • Remove the keyfile from the luks device holding your root volume
  • running sudo mkinitcpio -P
  • running grub-install and grub-mkconfig as described in the Arch wiki.

I haven’t tested that but those should be the basic steps.

Hello Stephane,

I have attached the output below:

[user@labrat ~]$ inxi -Fza
System:    Kernel: 5.14.8-arch1-1 x86_64 bits: 64 compiler: gcc v: 11.1.0 
           parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux root=UUID=7cd74c52-aa50-4089-9d60-f35c49ca77da rw rootflags=subvol=@ 
           quiet cryptdevice=UUID=b8ec394f-929f-4900-a5c8-46b13321d604:luks-b8ec394f-929f-4900-a5c8-46b13321d604 
           resume=/dev/mapper/luks-f2494b23-ef50-4423-b107-d7be0c080132 loglevel=3 nowatchdog 
           Desktop: GNOME 40.5 tk: GTK 3.24.30 wm: gnome-shell dm: GDM 40.1 Distro: EndeavourOS base: Arch Linux 
Machine:   Type: Virtualbox System: innotek product: VirtualBox v: 1.2 serial: <filter> Chassis: Oracle Corporation type: 1 
           serial: <filter> 
           Mobo: Oracle model: VirtualBox v: 1.2 serial: <filter> BIOS: innotek v: VirtualBox date: 12/01/2006 
CPU:       Info: 8-Core model: AMD Ryzen 9 3900 bits: 64 type: MCP arch: Zen 2 family: 17 (23) model-id: 71 (113) stepping: 0 
           microcode: 6000626 cache: L2: 4 MiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 49521 
           Speed: 3094 MHz min/max: N/A Core speeds (MHz): 1: 3094 2: 3094 3: 3094 4: 3094 5: 3094 6: 3094 7: 3094 8: 3094 
           Vulnerabilities: Type: itlb_multihit status: Not affected 
           Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown status: Not affected 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full AMD retpoline, STIBP: disabled, RSB filling 
           Type: srbds status: Not affected 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: VMware SVGA II Adapter driver: vmwgfx v: bus-ID: 00:02.0 chip-ID: 15ad:0405 class-ID: 0300 
           Display: x11 server: 1.20.13 compositor: gnome-shell driver: loaded: vmware unloaded: fbdev,modesetting,vesa 
           resolution: <missing: xdpyinfo> 
           Message: Unable to show advanced data. Required tool glxinfo missing. 
Audio:     Device-1: Intel 82801AA AC97 Audio vendor: Dell driver: snd_intel8x0 v: kernel bus-ID: 00:05.0 chip-ID: 8086:2415 
           class-ID: 0401 
           Sound Server-1: ALSA v: k5.14.8-arch1-1 running: yes 
           Sound Server-2: JACK v: 1.9.19 running: no 
           Sound Server-3: PulseAudio v: 15.0 running: yes 
           Sound Server-4: PipeWire v: 0.3.38 running: yes 
Network:   Device-1: Intel 82540EM Gigabit Ethernet driver: e1000 v: kernel port: d020 bus-ID: 00:03.0 chip-ID: 8086:100e 
           class-ID: 0200 
           IF: enp0s3 state: up speed: 1000 Mbps duplex: full mac: <filter> 
           Device-2: Intel 82371AB/EB/MB PIIX4 ACPI type: network bridge driver: piix4_smbus v: N/A modules: i2c_piix4 
           port: d200 bus-ID: 00:07.0 chip-ID: 8086:7113 class-ID: 0680 
Drives:    Local Storage: total: 128 GiB used: 13.38 GiB (10.5%) 
           SMART Message: Unable to run smartctl. Root privileges required. 
           ID-1: /dev/sda maj-min: 8:0 vendor: VirtualBox model: VBOX HARDDISK size: 128 GiB block-size: physical: 512 B 
           logical: 512 B speed: 3.0 Gb/s serial: <filter> rev: 1.0 scheme: MBR 
Partition: ID-1: / raw-size: 110.8 GiB size: 110.8 GiB (100.00%) used: 13.38 GiB (12.1%) fs: btrfs dev: /dev/dm-0 
           maj-min: 254:0 mapped: luks-b8ec394f-929f-4900-a5c8-46b13321d604 
           ID-2: /home raw-size: 110.8 GiB size: 110.8 GiB (100.00%) used: 13.38 GiB (12.1%) fs: btrfs dev: /dev/dm-0 
           maj-min: 254:0 mapped: luks-b8ec394f-929f-4900-a5c8-46b13321d604 
           ID-3: /var/log raw-size: 110.8 GiB size: 110.8 GiB (100.00%) used: 13.38 GiB (12.1%) fs: btrfs dev: /dev/dm-0 
           maj-min: 254:0 mapped: luks-b8ec394f-929f-4900-a5c8-46b13321d604 
Swap:      Kernel: swappiness: 60 (default) cache-pressure: 100 (default) 
           ID-1: swap-1 type: partition size: 17.19 GiB used: 0 KiB (0.0%) priority: -2 dev: /dev/dm-1 maj-min: 254:1 
           mapped: luks-f2494b23-ef50-4423-b107-d7be0c080132 
Sensors:   Message: No sensor data found. Is lm-sensors configured? 
Info:      Processes: 277 Uptime: 18h 8m wakeups: 6647 Memory: 7.76 GiB used: 2.34 GiB (30.2%) Init: systemd v: 249 
           tool: systemctl Compilers: gcc: 11.1.0 Packages: 897 pacman: 892 lib: 223 flatpak: 5 Shell: Bash v: 5.1.8 
           running-in: gnome-terminal inxi: 3.3.05 

Hi dalto,

I understand your instructions except for maybe the two points above.

The first I am almost sure you mean to just reinstall amd-ucode:

[user@labrat ~]$ pacman -Ss ucode
core/amd-ucode 20210919.d526e04-1 [installed]
    Microcode update image for AMD CPUs
extra/intel-ucode 20210608-1
    Microcode update files for Intel CPUs
extra/iucode-tool 2.3.1-4
    Tool to manipulate Intel® IA-32/X86-64 microcode bundles

For the second point, are you saying I must remove crypto_keyfile.bin?

[user@labrat ~]$ ls /
bin  boot  crypto_keyfile.bin  dev  etc  home  lib  lib64  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

If I do this, won’t my system fail to start? Does this not hold the key used to decrypt?

Correct. The amd-ucode file is stored in /boot so reinstalling that package will bring it back.

No. You probably want to keep that to decrypt your swap.

You need to remove the keyfile from the luksvolume which holds your root volume with the command:

luksRemoveKey <device> [<key file>] 

If you don’t do this, your keyfile will be used to unlock the root partition automatically.

I just I realized there is one additional minor step. You need to mkdir /boot/efi, I will add that above.

Hey @dalto,

Thank you for all your assistance. When I tried running mkinitcpio it complained the the kernel was missing:

[root@labrat boot]# mkinitcpio -P
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> ERROR: specified kernel image does not exist: `/boot/vmlinuz-linux'
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> ERROR: specified kernel image does not exist: `/boot/vmlinuz-linux'

So I ended up copying the files from the original location into the newly mounted /boot and then ran mkinitcpio -P and that worked fine. I then ran grub-mkconfig -o /boot/grub/grub.cfg followed by grub-install /dev/sda and rebooted.

This had the desirable effect of having grub run without asking for a password. I got the menu immediately and selected the default entry: just as you predicted, the system would automatically unlock the disk and boot straight into the login screen. (I skipped removing the key slot as I did not know anything about luks).

I then took another snapshot before proceeding to the second stage: after a bit of reading and realizing that there are two key slots in use (with cryptsetup luksDump /dev/sda1) I assumed that one is for auto-unlock and the other will remain if I remove the auto-unlock one. I was not sure which of the two to remove, but ended up using: cryptsetup luksRemoveKey /dev/sda1 /crypto_keyfile.bin which removed key slot 1 (leaving key slot 0). I then repeated the mkinitcpio/grub-mkconfig/grub-install ceremony and now my system works as expected:

  1. Grub shows up immediately on start
  2. Selecting the kernel loads it immediately (and the initial ram disk)
  3. At this point the kernel prompts for the root partition password
  4. After entering the password, root unlocks perceptively faster

I think this setup should be the default really, when the installer is told to “use the entire disk” but I guess there may be security repercussions I am not aware of.

I also wonder now what it means for system stability: when you take a snapshot of the btrfs partition WITH the boot stuff inside it, that includes the kernel as well. Now if I take a snapshot and then want to revert back to recover, that will not include the kernel right? So if I run into an issue with a kernel update, I would have to manually downgrade the kernel?

Thanks again for helping me with the setup. Really interested on getting some perspective on the points I raised about btrfs snapshots and potential security issues.

I thought it was mkinitcpio that installed the kernel there but I guess it is actually the mkinitcpio alpm hook that does that. I should have had you reinstall the kernel instead of running mkinitcpio.

You probably want to do that in that opposite order as a general rule.

I don’t think it should be the default for two reasons:

  1. There are some (minor) security concerns because now your initrams are unencrypted which would allow an attacker with physical access to your machine additional information about your system to help them attack it.
  2. :arrow_down:

Even if the kernel isn’t the cause of the problems, the kernel in /boot and the kernel modules in /usr/lib will have mismatched versions. If you restore a snapshot with a different kernel you will need to do one of two things:

  • chroot in and reinstall a kernel
  • After you restore the snapshot, copy the needed kernel modules from the other snapshot. In order to do this, you need to use a non-destructive snapshot restore method.

Since you need to boot off of something else to restore the snapshot anyway, I would probably just chroot in reinstall the kernel.

I believe the slow boot issue is not a grub issue but an issue with the number of iterations LUKS is doing. The number of iterations is set for each key slot in the LUKS header. Per default LUKS is setting millions of iterations. That can take a long time to decrypt the first key slot and start booting.

cryptsetup luksDump /dev/device

This will tell you the number of iterations per key slot. If it is more than 1 mio iterations you probably found the root cause for the slow boot. You then might want to change key slot 1 and use less iterations.

See also Section 3.4 in the cryptsetup FAQ

In theory boot encryption helps protect from something called an evil maid attack, when someone with physical access could, for example, tamper with your kernel/initramfs in order to obtain your passphrase the next time your type it. But again, in theory they could still mess with the unencrypted portion of grub or even the firmware even when boot is encrypted.

Exactly! This is why I think that in combination with btrfs the default should be an encrypted boot. :wink:

After careful consideration, I decided to forego some boot speed in favor of proper snapshot ability. Still, this thread has been very educational for me, so thank you everyone for your help.

I’m back to a fully-encrypted drive now.

Wait, I’m confused, you can install EOS without a boot partition??

Of course, that is the default.

Keep in mind, we are talking about a partition mounted on /boot. If it is an EFI system you will still have an ESP mounted on /boot/efi

1 Like

Thx for the answer! But I have to admit that I still don’t get it. What do you mean by mounted on /boot? How can it be mounted on /boot if there is no /boot?

(Sorry, still a noob at Linux :flushed: But I try to learn!)

edit: I just DDG’d “Install linux without boot partition” and all results are about dual boot systems.

/boot can be part of the / partition or it can be it’s own partition. The default is to make it part of the / partition.

1 Like

Is it the default when you use BTRFS? Because it wasn’t the default for me with Ext4. Anyway, that seems to be the easiest way to get full disk encryption.

edit: Do I maybe confuse this with the ESP partition? Was that the small partition that has to be FAT32?

It should be the default no matter what filesystem you choose.

Are you sure you have a separate partition mounted at /boot?

Yes, that is your ESP.

1 Like

Ok ok, I think I get it now. ESP contains the bootloader, I confused that with the boot partition. Damn, feel like an idiot now. Thx Dalto!