However, i noticed that during boot process, when asked the encryption password, boot loader takes a very long time to unlock the disk. In my laptop which has a 4-core 8-thread i7 CPU, it can take up to 30~40 seconds. It is a very long time. I understand it is not a Tumbleweed only issue, as I found posts in Arch forums reporting same problems.
Just as a comparison ubuntu, which uses unencrypted /boot partition, and then encrypted LVM volumes. In ubuntu, disk unlock password is asked after the boot loader. and unlocking the disk is instant. So I thought I could do that. A bit more reading in Tumbleweed forums and documentation, I also found that it is recommended not to move /boot out of btrfs volume. Possibly due to snapper and btrfs rollback?
The question is. Is there any way to keep full disk encryption, btrfs partition with snapper and all the cool features it offers, but have a faster disk unlock during boot?
This is mostly a BIOS issue. Grub is using BIOS calls (or UEFI firmware calls) for its I/O. This is pretty fast on the computer where I do it. But it is a lot slower on a KVM virtual machine where I also do that. And I think it is made more complex by using “btrfs”.
I’m mainly using “ext4”. I mostly do have a separate “/boot”, and then grub does not need to deal with the crypto. But I have four systems (two on real hardware and two in a VM) where I use crypto with “/boot” part of the encrypted root file system.
As you surmised, a separate “/boot” can be a problem with “btrfs” and rollback. The problem is that with a separate “/boot”, your rollback might take you to a kernel that does not exist in “/boot”.
The problem is that the base kernel is in “/boot”, while the modules used by that kernel are in “/lib/modules” which is part of the root file system. So if you rollback, you might finish with a mismatch.
I also had noticed the extremely long latencies both after the initial password challenge (prior to GRUB) and again (after GRUB) on a VMware virtual machine… But didn’t think about it too much.
Although always a possibility, I don’t know that there should be a penalty accessing a software BIOS (for the virtual machine) with the assumption that everything that might be slow due to limited hardware resources should run lightning fast as software where the app would likely run without those limitations.
Whatever the reason might be… Yes, it’s very slow… For me, it’s longer, a little over 60 seconds. If I had to reboot this machine often it could be frustrating. And that’s for <each> of the two times the password has to be supplied (Needs attention, can’t just walk away and let it run).
I haven’t timed it recently. But I think it is a lot faster if I set the virtual disk to use “virtio” rather than IDE or SATA. There’s less emulation overhead with “virtio”.
Where I am doing this on a real machine, the main delay is at the POST stage, where I see the manufacturer’s splash screen. Once I get past that, it is pretty fast. But, again, that depends on the BIOS implementation.