Since years I've used the partition encryption option offered by the installer.
Now after applying Ubuntu onboard disk tool to setup encryption also for the secondary physical disk, I've found the following.
- There is an option to mount this disk on system start but it does not work
- I can manually select the disk and choose the option "unlock"
- Additionally I have after that to choose the "mount" version
- Given the above steps were not very user friendly, here comes also some ugliness: the system generates an incremented enumeration so that the mount point assumed in the system (e.g. by the Docker daemon) becomes invalid.
What to do? Is there an option just to type in the encryption password during system startup also for the second disk?
- I use Ubuntu 20.04.3 LTS
- The disks utility is called "Disks - gnome-disk-utility 3.36.3 - UDisks 2.8.4 (built against 2.8.4)"
While the primary disk's encryption triggers an on-boot prompt, the second disks' encryption unlock needs to be dialed on manually. Only then it's possible to mount the data volume. It would be better to have both steps on startup as happens to the primary volume.
There is a corresponding setting but it seems to be ignored by the system.
First of all, it looks like we are dealing with LUKS encryption based on what I see from your images above. The rest of my answer from here assumes you are using LUKS encryption.
I've not used any tools that automate setting up automatic decrypting of partitions, but I have done it manually, and that should work for you in this case.
Rather than reinvent the wheel, I will provide a little bit of overview, outlining what needs to happen, and then I'll point you to a post online that documents the process.
The Overview
Your system needs to know how to handle the secondary encrypted partition. To inform your system how to handle this partition, you need to create an entry for it in the
/etc/crypttab
file. This is where you will tell the system how to decrypt the partition. It can be done with a keyfile that is stored on a primary encrypted partition. It can be accomplished with the decrypt_derived script which uses a previously decrypted partition for decryption of the secondary partition. Both of these approaches are documented in the page linked below. There are actually lots of options if you can do any shell scripting and want to dig into LUKS key scripts. For example, you could decrypt your system with a USB stick but fall back to password if the USB stick is not present.Simply updating
/etc/crypttab
is not going to be sufficient. For a fixed disk, ecryption should happen at boot time, so you must runupdate-initramfs
to build the boot files with the changes you just made. The post I link to below simply updates the currently running kernel version. Check the command line options for this command to see how to update all versions if you want to do that.Once the system knows how to decrypt the partition, an entry in
/etc/fstab
should take care of properly mounting the partition at boot time after it has been decrypted.The Redirect
As I mentioned, someone else has already done a write-up on specific steps to take to make this happen. You'll find those instructions here. I just have a couple notes to make. In the author's
/etc/crypttab
file, he/she specifies the path to the disk for the source parameter. I personally prefer specifying a UUID simply because it will remain the same even if the path to your device changes, but if you're certain the path to your device will never change, using that will work. Should you choose to use your UUID, the line in your crypttab file would look more like:part2_crypt UUID=<uuid> <path to key file> luks
or
part2_crypt UUID=<uuid> <part1_crypt> luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived
Of course, the value for
<part1_crypt>
would be the first parameter (name) listed for your primary encrypted disk in this file. You can find the UUIDs of your LUKS encrypted disks by runningsudo blkid | grep "crypto_LUKS"
Grepping for
keyctl
is probably not necessary in your case, and in my experience on Ubuntu 20.04, I have not had to edit/etc/default/grub
either as the author of the post does.