Booting up with LUKS + Btrfs is insanely slow

Hi!

I'm currently trying to set up dual-booting between Windows 10 and Manjaro Linux on a work laptop.
I also wanted to set up full disk encryption.

TL;DR

Is it normal that my laptop takes 10 minutes to boot up from an SSD drive?
It boots up in a few seconds when not using LUKS.

The full picture:

On the Windows side VeraCrypt did an excellent job. But on Manajro I was unable to get a well-working encrypted system.

I've found and followed a guide by Octez:

I've been following that using Manjaro Architect to install the system and KPartitionManager to partition the disks, as it was easier for me to do.

After my 6th (IIRC) attempt I've finally got a system that booted into the KDE desktop. It didn't mount my swap or extra data partitions (both using LUKS encryption).

But - it managed to mount the LUKS-encrypted Btrfs root filesystem (with /boot on the same filesystem, and /boot/efi mounted to an unencrypted Windows partition). So it was something.

However - the boot process took like 5-10 minutes and I was sure it would not work at all
The laptop is an MSI Alpha 15 A3DD with Ryzen 7 CPU, 512 GB nvme SSD and 32 GB of RAM.

Also - for some reason I had to start and enable NetworkManger service manually.

So even if I got everything working in that install, it'd be so slow I would not be able to work on it.

I have done another installation, using the same partition layout, only this time without using LUKS, and I got a fast, working Manjaro KDE desktop up in no time!
(Thought I still had to start and enable Network manager manually - is that a bug in M-A?)

So my question is:

Is it a known problem that LUKS full-disk encryption doesn't work fast with Btrfs or something?
Maybe there's a solution to this?

Full system specs:

$ inxi -Fxzc0
System:    Host: unfa-alpha15-manjaro Kernel: 5.6.16-1-MANJARO x86_64 bits: 64 compiler: gcc v: 10.1.0 
           Desktop: KDE Plasma 5.18.5 Distro: Manjaro Linux 
Machine:   Type: Laptop System: Micro-Star product: Alpha 15 A3DD v: REV:1.0 serial: <filter> 
           Mobo: Micro-Star model: MS-16U6 v: REV:1.0 serial: <filter> UEFI: American Megatrends v: E16U6AMS.10C 
           date: 10/30/2019 
Battery:   ID-1: BAT1 charge: 44.7 Wh condition: 49.5/53.4 Wh (93%) model: MSI BIF0_9 status: Charging 
CPU:       Topology: Quad Core model: AMD Ryzen 7 3750H with Radeon Vega Mobile Gfx bits: 64 type: MT MCP arch: Zen+ rev: 1 
           L2 cache: 2048 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 36750 
           Speed: 1355 MHz min/max: 1400/2300 MHz Core speeds (MHz): 1: 1777 2: 1462 3: 1369 4: 1321 5: 1204 6: 1290 7: 1286 
           8: 1268 
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Navi 14 [Radeon RX 5500/5500M / Pro 5500M] vendor: Micro-Star MSI 
           driver: amdgpu v: kernel bus ID: 03:00.0 
           Device-2: Advanced Micro Devices [AMD/ATI] Picasso vendor: Micro-Star MSI driver: amdgpu v: kernel bus ID: 07:00.0 
           Display: x11 server: X.Org 1.20.8 driver: amdgpu FAILED: ati unloaded: modesetting,radeon 
           resolution: 1920x1080~120Hz 
           OpenGL: renderer: AMD RAVEN (DRM 3.36.0 5.6.16-1-MANJARO LLVM 10.0.0) v: 4.6 Mesa 20.0.7 direct render: Yes 
Audio:     Device-1: Advanced Micro Devices [AMD/ATI] Navi 10 HDMI Audio vendor: Micro-Star MSI driver: snd_hda_intel 
           v: kernel bus ID: 03:00.1 
           Device-2: Advanced Micro Devices [AMD] Raven/Raven2/FireFlight/Renoir Audio Processor driver: N/A bus ID: 07:00.5 
           Device-3: Advanced Micro Devices [AMD] Family 17h HD Audio vendor: Micro-Star MSI driver: snd_hda_intel v: kernel 
           bus ID: 07:00.6 
           Sound Server: ALSA v: k5.6.16-1-MANJARO 
Network:   Device-1: Realtek RTL8822CE 802.11ac PCIe Wireless Network Adapter vendor: AzureWave driver: rtw_pci v: N/A 
           port: f000 bus ID: 05:00.0 
           IF: wlo1 state: down mac: <filter> 
           Device-2: Realtek vendor: Micro-Star MSI driver: r8169 v: kernel port: e000 bus ID: 06:00.0 
           IF: enp6s0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 2.29 TiB used: 8.85 GiB (0.4%) 
           ID-1: /dev/nvme0n1 vendor: Samsung model: MZVLB512HAJQ-00000 size: 476.94 GiB 
           ID-2: /dev/sda vendor: Seagate model: ST2000LM015-2E8174 size: 1.82 TiB 
Partition: ID-1: / size: 210.85 GiB used: 8.82 GiB (4.2%) fs: btrfs dev: /dev/nvme0n1p5 
           ID-2: /home size: 210.85 GiB used: 8.82 GiB (4.2%) fs: btrfs dev: /dev/nvme0n1p5 
           ID-3: swap-1 size: 31.25 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/nvme0n1p4 
Sensors:   System Temperatures: cpu: 53.5 C mobo: N/A 
           Fan Speeds (RPM): N/A 
           GPU: device: amdgpu temp: 55 C device: amdgpu temp: 50 C fan: 65535 
Info:      Processes: 298 Uptime: 3m Memory: 29.38 GiB used: 1.16 GiB (3.9%) Init: systemd Compilers: gcc: 10.1.0 Shell: bash 
           v: 5.0.17 inxi: 3.0.37

Yes it is a know problem. But is has nothing to do with Btrfs or LUKS. The problem is grub.

Don't use grub to decrypt your Root file system. You will need an unencrypted boot.

1 Like

Hmm, could you point me to some resources detailing this process?
Manjaro Architect has shown me three different bootloaders I could choose, but since I am no familiar with others than Grub, I went with that.

Simply use a boot partition that is not encrypted. The problem with grub is that it can't use the Hardware functions to speed up the luks opening process. If you switch to a unencrypted boot, grub will start the initrd. In it, systemd can open the luks device which is a lot faster. In addion you can make typos without the need of a hard reset.

I don't know any other boot-loader that can boot a completely encrypted system.

So if I used a non-encrypted /boot partition, Manjaro would start up as fast as usual?
But what about not mounting other encrypted filesystems apart from the root one? Could that be related?

systemd-boot will recognize a windows system and systemd-boot works with LUKS2 - and you can use full disk encryption as systemd-boot uses the $esp (efi) partition for kernel images.

Due to my curiosity - I have done some installations and made my notes available as guides.

Decrypting a partition will always take more time than reading an unencrypted partition.

Also take into consideration the amount of round trips the encryption engine is configured for.

The default Manjaro installation using Calamares is using a very high number of reoundtrips. Of course the more roundtrips the more resilient the storage is against brute-force - but that has to be weighed against your requirements and how secretive you are and how sensitive your data is.

2 Likes

No, other LUKS encrypted devices need entries in /etc/crypttab and then mount the filesystem with an entry in fstab. But this is independently form the root fs and if it is encrypted or not. But if you have multiple devices you might need to type in the password multiple times or use a key file.

If you put kernel images on the $esp then it should not be called "full disk encryption". Because it is basically the same as an unencrypted boot. But of course if the kernel images are not on a encrypted partition, the system boots a lot fast and your kind of point less boot directory can be encrypted.

1 Like

I've cleaned the slate and reinstalled the system once again with LUKS encryption and an unencrypted /boot filesystem (albeit it's Btrfs).

It took a long while to show any progress after me giving it the LUKS password for the root filesystem:

image

It still took like 5 minutes to show me the log-in prompt, and after that if took another 2 minutes for it to accept the user password and show any progress on starting the desktop environment.

After I logged it it took like 2 another minutes to show the desktop and the system is taking minutes o discover hardware like the soundcard or WiFi networking interface.

So the problem is not just GRUB having issues with encrpted /boot/ becasue now I don't have that and it's still unusably slow.

What could it be?

Not to mention that the system failed to open other LUKS-encrypted paritions (swap, and an additional data partition and another disk).

The /etc/crypttab references files /etc/mypassword[12]and /etc/cryptfs.key.

None of these files exist on my disk, so maybe that's why the extra filesystem weren't mounted. But swap didn't work either.

No - the crypttab file don't reference anything. The content are commented usage examples.

The more complicated you make your setup the longer time will be needed to process and decrypt the volumes.

Default /etc/crypttab
➜  ~ sudo cat /etc/crypttab
[sudo] password for fh: 
# Configuration for encrypted block devices.
# See crypttab(5) for details.

# NOTE: Do not list your root (/) partition here, it must be set up
#       beforehand by the initramfs (/etc/mkinitcpio.conf).

# <name>       <device>                                     <password>              <options>
# home         UUID=b8ad5c18-f445-495d-9095-c9ec4f9d2f37    /etc/mypassword1
# data1        /dev/sda3                                    /etc/mypassword2
# data2        /dev/sda5                                    /etc/cryptfs.key
# swap         /dev/sdx4                                    /dev/urandom            swap,cipher=aes-cbc-essiv:sha256,size=256
# vol          /dev/sdb7  

Hmm. You are right, all of the file's contents are commented out.

So why after using Manjaro-Architect to install a system and setting up the encryption, when I boot it up it doesn't open the encrypted partitions?

You need the crypttab only if you want to open additional crypt devices. You don't need to put the Root file system in it. Only other luks devices that you want to open.

Your screenshot shows that systemd is waiting for a devices that never showed up. Make sure all entries in crypttab and fstab are correct.

Architect has a lot of bugs. I always check the created config files after the installation and before I reboot.

Ok. That's too bad. It's the only tool I know that can help me install Manajro the way I want on this laptop (Btrfs, LUKS and dual-booting with Windows - makes me sad ).

Ok, what should I do now to get these extra filesystems to open and mount at boot time?

(Assuming it will magically fix how slow everything is)

You could just follow the above mentioned guide.

When you have completed the installation and have a basic system you can take the package list from any profile and feed to pacman - making it possible to circumvent the default Manjaro install.

Thanks, I missed your link.

You should really follow the guide.

Also don't do everything at the same time. Install the system as described in the guide. Then reboot and check for errors. After that create a crypttab entry. Reboot. Check for errors and check if the luks device is open and the /dev/mapper device is available. Then create a fstab entry so the /dev/mapper device is automatically mounted.

Ok, I'll give it a try.

Maybe the bad performance somehow is related to me using Btrfs on /boot?
I see that the guide uses FAT32 for it.

I can't take this. The process of getting this to work is inhuman.
I'm gonna install a clear system without encryption, I don't have time to deal with this mess.

Thank you for your help, but it seems to me that what I want to do simply isn't viable at this point in time. And I can't spend an entire week getting this perfectly set up, avoiding all the bugs and issues.

I've been following the guide, but what I need is to use an existing EFI partition to dual-boot with Windows. I've mounted it at /mnt/boot/efi, and it seems the SystemD Boot fails to work with that, so now I'd need to start over and I've just had enough.

The guide is a little bit different since it uses systemd-boot and not grub. systemd-boot requires the initd in the efi partition.

I used Btrfs only once and it failed horrible on me. So I have no experience how long it would take to boot a fairly modern system.

Forum kindly sponsored by