Hmm, it shouldn’t take that much longer to get to the login screen. Maybe a few seconds longer or so, but not 23s.
1 Like
I don’t know what might contribute to a long startup time. I have a 2TB disk. This start-up time is acceptable for me.
I occasionally mis-type my passphrase, which drops me to a grub rescue prompt. I just power-cycle and enter the passphrase again.
My laptop is quite snappy, so I’ll stick with the full disk encryption.
Yeah, this is why I use an unencrypted /boot partition. That way, the OS handles the decryption (not GRUB) and lets you try multiple times (it also supports LUKS2, which is way better in so many ways).
1 Like
I see. Thanks for the suggestion. I will try that. Seems like that should allow it to boot up much faster.
Some references:
To give you some details, this is what my current partition layout looks like on my desktop:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 1.8T 0 disk
└─sda1 8:1 0 1.8T 0 part
└─sda1_crypt 254:3 0 1.8T 0 crypt
└─Crypto--Data-Home 254:4 0 1.8T 0 lvm /home
nvme0n1 259:0 0 465.8G 0 disk
├─nvme0n1p1 259:1 0 476M 0 part /boot/efi
├─nvme0n1p2 259:2 0 477M 0 part /boot
└─nvme0n1p3 259:3 0 464.8G 0 part
└─nvme0n1p3_crypt 254:0 0 464.8G 0 crypt
├─Crypto-Root 254:1 0 425.6G 0 lvm /
└─Crypto-Swap 254:2 0 29.8G 0 lvm [SWAP]
nvme0n1p1 here is the ESP (EFI System Partition). nvme0n1p2 is my unencrypted boot partition. nvme0n1p3 is just a giant encrypted block. Inside nvme0n1p3_crypt (the name for the mounted encrypted volume), I have a LVM setup with two volumes: Crypto-Root (for /) and Crypto-Swap (for swap). Meanwhile, sda1 is a giant encrypted block. Inside sda1_crypt (the name for the mounted encrypted volume), I have a LVM setup with only one volume: Crypto--Data-Home (for /home).
The only difference with my Framework is that /home gets put in the same volume group as / and swap (since there’s only one storage medium on there). So basically, you’d see Crypto-Home in addition to Crypto-Root and Crypto-Swap. Everything else (crucially, the setup of /boot/efi and /boot) remains the same.
1 Like
Thanks! It turns out that my /boot/efi is not encrypted. So, I don’t know why it’s taking so long to boot up.
Edit: I ran the following command, and it took 3 seconds.
sudo cryptsetup -v luksOpen --test-passphrase /dev/nvme0n1p2
Edit 2: Oh, here is a video on how to set this up with /boot unencrypted. Now I notice above that you have both /boot and /boot/efi. So, I need to add that unencrypted /boot partition. Right now it’s under the ‘/’ mountpoint.
Are your kernels stored in /boot/efi? Or in /boot? Because if they’re stored in /boot and you don’t have a separate (unencrypted) /boot partition, you’ll run into slow boots since GRUB has to handle the decryption.
1 Like
Exactly! Sometimes people will setup their ESP as their /boot partition, but I don’t like to do that since that partition has to be VFAT, whereas I would prefer my /boot partition to be a regular (read: ext4) partition. Hence I keep separate /boot and /boot/efi partitions.
1 Like
It was a little tricky, but if anyone installing Manjaro wants a quicker boot experience, I’ve put some instructions on how to do that over here:
In short, with the calamares installer (which is what Manjaro uses) you would need to partition manually with an unencrypted /boot/ partition. When you specify that partition, it seems that you must supply a trailing /. Additionally, you will need to update grub, per the instructions which I linked to, after booting into the newly installed system in order to avoid being prompted an extra time for the encryption passphrase (which it doesn’t need in order to open the boot partition).
So, the next problem is that I don’t know how to get the encrypted swap partition working, let alone get it working for hibernation. By default, the swap partition is not being used, and my attempts to turn it on have not been successful.
The desired setup would have the root partition and swap partition in the same encrypted container, as Chiraag_Nataraj indicated above, in order to avoid having to enter the encryption passphrase twice. However, the path of least resistance for me may be to use an encrypted swap file on the root partition.
@Paul_Stone Here’s how I setup partitions during install (I installed Debian, but the partitioner should be fairly similar if you do the manual partitions):
- Delete existing partition table. Yes, that includes the EFI partition if you have one, since you’ll recreate it anyway.
- Create a new partition. Set the type to EFI and the size to whatever you want (looking at my current desktop, I set it to about 500MiB).
- Create a new partition. Set the type to ext4, the mountpoint to
/boot, and the size to whatever you want (again, I use about 500MiB on my desktop). - Create a new partition. Set the type to crypt and set it to use the rest of the disk.
- In Debian, there’s another sub-menu at the partitioner to setup encrypted volumes, and I enter that and setup my passphrase and such at this step. I don’t know if Calamares does something similar or if it comes up at the previous step when you set the type of the partition to crypt. Either way, I will assume that at this point, you have created an encrypted container which takes up the rest of the disk (after your EFI partition and
/boot). - Now, at the partitioner’s main screen, I see a new ‘disk’, which is the encrypted volume I setup and has been mounted to expose the internal space.
- Create a new partition in the encrypted volume and let it take up the entire space. Set the type to LVM.
- Now, in Debian, there’s another submenu to setup LVM, so I enter that.
- Here, I can create a volume group (I usually name it Crypto) and several logical volumes inside of that volume crypto. This is where I create Root, Home, and Swap.
- Once I exit the LVM setup, I see that three new ‘disks’ have appeared, each one corresponding to a logical volume I created and unformatted at the moment.
- At this point, I can go to each of those and setup the appropriate partitions (
/,/home, andswap). - Once the install completes, everything should “Just Work”.
The one thing I don’t know is if Calamares uses a partitioner other than partman (which is what Debian uses). If it does, then the way the options are exposed to you (especially for crypto and LVM) may be different.
2 Likes
Thanks so much, Chiraag_Nataraj.
I think there is some LVM setup capability in the Calamares installer. I will look into this further when I get a chance.
Yes. Major speed issues with LUKS.
My 7000 MB/s drive craps out at 900 MB/s with LUKS. All the NVMe advantage goes to trash. Could have gotten those speeds with SATA.
I’m wondering if I use an unencrypted Ubuntu install with a BIOS-set HDD password on a Samsung 980 Pro actually encrypts the drive properly. If so that would probably be much better performance.
I read your last comments a little confused. I encrypted root and I am booting way quicker than 20 seconds until login screen, more like 2-4, at most. I don’t think your speed problems are as black and white as encryption yes/no. There’s something else cooking.
3 Likes
Hi, sorry to be waking up an old post, but the frame.work support team pointed me here.
I am installing Jammy Jellyfish Ubuntu 22.04 on a frame.work 13" chassis and I wish to engage LUKS encryption. The stock installer allows for this, but after USB install complete and booting from SSD the laptop asks for the decryption password each and every time. I wish to automate this and also make use of the inbuilt TPM2 chip to hold the appropriate secret. Do you have a detailed set of instructions on how to engage LUKS on a 13" chassis with Intel Gen11 mobo making use of the TPM2 capabilities? I want a system as easy and transparent as BitLocker while still providing storage encryption. ChatGPT says this is a tricky and delicate process and may change depending on the specific models of firmware and hardware involved, so I wish to hear this from you first. I’ll also check on the community forums for driver pack install (once I can actually get a shell coming up after putting the LUKS issue to bed that is).
Right now I’m dead in the water because the very password I used when the installer asked for (and wrote it down carefully in my secure vault and retyped at SSD boot time) is rejected and ultimately does not work. My next step is likely to boot from the stock installer USB stick and somehow get into a manual root shell and skip the install step, so I’m running entirely from the USB (not quite sure how to do this), and then work some kind of magic to either reset the LUKS password or manually unlock it as root…
I should also note that the CAPS lock light does not toggle on my stock keyboard so I tried entering my password, and when it failed pressed the CAPS lock sight unseen and retried the same password
Any next steps? I tried my ChatGPT but I think this sequence is too detailed and I’m bound to do something wrong by following less informed directions.
Thanks.
Not an expert but I’m myself using disk encryption with TPM unlock on Ubuntu: some word might not be 100% accurate.
Ah… chatgpt… Not sure where that info came from…
The only part firmware specific is probably settings up Secure Boot with a custom new key. I have a FW 13 AMD and adding a db key was pretty easy compared to my experience with bios/uefi setting in other laptops. I think uefi setting are a little different in FW13 Intel 11th but shouldn’t be too hard to find the right options. Worst case scenario you need to use EFI key tool(see the link below).
You want secure boot enabled to validate your boot components because don’t want someone who has stolen your device to boot an altered boot stack to get your TPM secret.
Moreover you have to decide under which conditions the TPM secret can be obtained. You have to choose a set of PCR. Depending on your choice you may have to enter your password during boot after a kernel upgrade or after a firmware upgrade. So you still need a password.
Using TPM2 unlock on Ubuntu 22.04 is possibile. I use it on Ubuntu 23.10 and PopOS 22.04. Still it’s harder than it is on other distros. Fedora for example ships some more modern version of some tools (systemd-cryptenroll & co.) and I’ve noticed that guide for fedora are shorter than those for debian/Ubuntu.
I hope that the upcoming Ubuntu 24.04 version will make stuff easier. Haven’t check yet.
On this forum this thread is for fedora:
For debian/Ubuntu this is the way:
https://blastrock.github.io/fde-tpm-sb.html
Both links also covers encrypted hibernation. If you don’t feel like compiling the kernel and you don’t care about hibernation skip that part
I haven’t fully understood the situation. Were you installing or have you already installed Ubuntu 22.04?
To diagnose boot/LUKS/disk-related issues a good idea is to boot a live iso from usb. This way you have a full system available. In the initramfs the diagnostic tools are limited.
If you don’t use US keyboard beware of using the correct keyboard layout when you enter your password.
Thanks very much for the replies. I started with a completely empty SSD, this is a brand new system I’m setting up.
I may try re-installing from scratch since even with entering the password twice I might have made a keying error.
I am using a typical US keyboard.
Can I use the Ubuntu install ISO as a “live boot” product and boot into the key instead of doing an installation?
I will never be using hibernation or suspension since the purpose of this sytem is to be an always-on crypto miner / validator (I could be docked if the machine is offline).
I’ll do more research to determine the appropriate PCR settings.
Update : After some consideration, I have decided this is much too volatile a setup for my home server. I will forego disk encryption entirely. I yearn for a solution as easy to engage / disengage as Windows BitLocker. Too many opportunities to cause huge damage if I get something little wrong - I see this whole subsystem as very brittle, especially for those who don’t have decades of experience. This server will be operating on mission-critical data but I lack the confidence to move forwards with disk encryption. Thanks to all who responded.
I use it on Fedora, I do not use it on Ubuntu myself. LUKS in and of itself, is fine and reliable.
I know this is an old thread, but just throwing in that luks works fine on the Framework 16. No reason for it not to.
In my particular case, I have standard EFI partition, and a few unencrypted boot partitions for various OS’, then a massive LUKs encrypted btrfs formatted partition for the rest of the drive, which currently contains Fedora 39, Ubuntu 22.04, and Arch Linux all installed under their own designated subvolumes. This way all three OSs are unlocked with the same luks password and space isn’t wasted.