TPM-backed Full Disk Encryption is coming to Ubuntu - Discussion

This sounds like a snapd bug (which is the “server” it can not communicate with in this case… i.e. snapd crashed/died for some reason) rather than anything related to disk encryption… you should file it with:

ubuntu-bug snapd

Microsoft’s BitLocker uses a combination of centralized and local storage to store encryption keys. Encryption keys are stored in a key vault (KEK) that is stored on a secure location, such as a server. The key vault is protected by a password or recovery key that must be known by the BitLocker administrator.
I think some native implementation for key recovery in an Enterprise environment, also for Ubuntu, would be essential.

1 Like

I’ve been developing a key recovery for LUKS-based encryption since 2019 and I wonder if there’s some way to participate in discussions regarding key recovery / key escrow for Ubuntu… is there any existing platform for such design discussions or integration questions?


I tested fde with tpm. I could successfully install Ubuntu Desktop 23.10 on an Dell XPS Laptop. I wrote down the recovery key. Then I rebooted and cleared TPM. It was very difficult to type in the recovery key (only * shown, no option to show the typed in sequence; which keyboard layout is active (I think US)). Anyway, finally I could boot with the recovery key.


  • where do I file bugs?
  • how can I use the TPM again for unlocking? how to “repair” the cleared TPM?
  • where do I find further information? The blog post is interesting, but I could not find links to places, where this feature is discussed.



1 Like

I’m no expert, but I would assume refreshing the pc-kernel snap in the booted system should restore the keys to the TPM.

I think as it stands, there isn’t a ‘re-install’ option for snap packages, so you would probably have to install a different kernel version then revert back.

Maybe someone working at ubuntu has a better solution than this.

This is indeed a bug. I’ve reported this myself along with another: Bug #2036631 “FDE: snap recovery --show-keys hangs, times out” : Bugs : snapd package : Ubuntu

It looks like a fix is coming eventually but not sure when.

Thanks. I tried that, but after reboot it asked again for the recovery key. I tried to refresh pc-kernel, but it failed with TPM errors (“TPM is in DA lockout mode” and "cannot set next boot: cannot reseal the enc key: cannot validate key data: cannot create context for SRK: a resource at handle 0x…… is not available on the TPM).

The fix is in snapd 2.61. I installed that version with snap refresh snapd --channel latest/beta, which fixed the timeout-error.

On my (broken) system with cleared TPM I got another error instead (which is in this context good, I guess).

Fehler: cannot run keymgr tool: cannot run
        ["/snap/snapd/20515/usr/lib/snapd/snap-fde-keymgr" "add-recovery-key" "--key-file"
        "/var/lib/snapd/device/fde/recovery.key" "--devices"
        "/dev/disk/by-partuuid/8d4fa6a7-9683-4939-82db-6ae6e722f141" "--authorizations"
        "keyring" "--devices" "/dev/disk/by-partuuid/0c7f4a6d-255f-4122-8767-71e4345ec870"
        "--authorizations" "file:/run/mnt/data/var/lib/snapd/device/fde/ubuntu-save.key"]:
        ----- stderr: error: cannot add recovery key to LUKS device: cannot add key:
        cryptsetup failed with: Schlüsselfach 1 ist voll, bitte wählen Sie ein anderes.
1 Like

After a few days of using this new feature, I am getting an error with apt mentioning it cannot upgrade the kernel due to a read only file system.

The following packages will be upgraded:
1 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
75 not fully installed or removed.
Need to get 0 B/3,737 kB of archives.
After this operation, 28.8 MB of additional disk space will be used.
(Reading database ... 156176 files and directories currently installed.)
Preparing to unpack .../linux-headers-6.5.0-10-generic_6.5.0-10.10_amd64.deb ...
Unpacking linux-headers-6.5.0-10-generic (6.5.0-10.10) over (6.5.0-10.10) ...
dpkg: error processing archive /var/cache/apt/archives/linux-headers-6.5.0-10-generic_6.5.0-10.10_amd64.deb (--unpack):
 error creating symbolic link './lib/modules/6.5.0-10-generic/build': Read-only file system
dpkg: error while cleaning up:
 unable to remove newly-extracted version of '/lib/modules/6.5.0-10-generic/build': Read-only file system
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

I am unable to even install most apt packages without running into this error. I have tried the following:

  1. sudo apt clean && sudo apt update && sudo apt upgrade
  2. sudo dpkg --configure -a && sudo apt-get -f install

This does not resolve the issue.

I have checked sudo apt list --upgradable -a, the output is as follows:

linux-headers-6.5.0-10-generic/mantic-updates,mantic-security 6.5.0-10.10 amd64 [upgradable from: 6.5.0-10.10] 
linux-headers-6.5.0-10-generic/now 6.5.0-10.10 amd64 [installed,upgradable to: 6.5.0-10.10] 

As this new experemental feature requires snap to be installed, I am thinking that the snap is the problem here as the filesystem that contains the kernel is marked as read only. Am I correct?

/run/mnt/data/var/lib/snapd/snaps/pc-kernel_1500.snap on /usr/lib/modules type squashfs (ro,relatime,errors=continue,threads=single) 

How would I get rid of this issue without reveting back to just using a password for login authentication?

I believe the linux-headers are included in the pc-kernel snap. So you shouldn’t need the .deb linux-headers packages.

I would say just apt-get remove linux-headers*

Possibly some other package on your system has tried to install them as a dependency.

Maybe you can try running apt-cache rdepdends --installed linux-headers-6.5.0-10-generic first to see which package installed it.

Has anyone else had trouble installing with TPM-FDE? Since the official Mantic release (23.10.1 ISO), I have NOT been able to perform a successful install.

It runs the entire installation, then upon reboot it prompts for the recovery key instead of booting into the newly installed system.

I have tried on a VM (cloned from a working Mantic system with TPM-FDE using the old daily ISO), and on a Dell laptop, but both have the same issue.

I have opened a bug report, but I’m curious how many people are seeing the same problem.

Tried sudo apt remove linux-headers* and I get a dpkg error:

The following packages will be REMOVED:
  linux-headers-6.5.0-10 linux-headers-6.5.0-10-generic
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 83.9 MB disk space will be freed.
Do you want to continue? [Y/n] Y
dpkg: error processing package linux-headers-6.5.0-10-generic (--remove):
 package is in a very bad inconsistent state; you should
 reinstall it before attempting a removal
dpkg: too many errors, stopping
Errors were encountered while processing:
Processing was halted because there were too many errors.
E: Sub-process /usr/bin/dpkg returned an error code (1)

Output of sudo apt-cache rdepends -- installed linux-headers-6.5.0-10-generic:

Reverse Depends:

Okay, I’m going by memory here, but I remember there was a similar bug with another .deb package which pc-kernel takes the place of.
That was causing the same/similar error message because the parts of the filesystem managed by the .deb package are actually read-only due to pc-kernel snap.

I would suggest raising a bug report for this, because it seems like the mechanism for preventing linux-headers-* deb package is failing.

There is already a bug report about it on launchpad

1 Like

If you’re in this inconsistent state and dpkg requires to reinstall the packages, you can force the removal of the package with dpkg option --force-remove-reinstreq

For instance:
sudo dpkg --purge --force-remove-reinstreq linux-headers-6.5.0-10-generic

To list the packages that are half-installed, use the following:
dpkg -l "linux-headers*"

Kernel headers are not the only package affected; everything that tries to write to kernel-protected directories will be like extra modules or firmware.

This is a known issue and is being worked on.

Yup, I’ve also been having this issue. I also have a Windows dual boot on this system, I wonder if that’s related.

TPM-based LUKS FDE within the installer is a great option for a corporate environment.

But for the average use, I believe FIDO2 is more understandable and accessible (and has some other technical advantages for non-average-user use cases). Are there any plans to add FIDO2 to the installer? I really think that would be a huge improvement to privacy and security in Ubuntu.

1 Like

Hi James, sorry for the late reply.

On my Dell XPS 13, I needed to turn off both Raid and Absolute in the BIOS to prevent this issue, can you check that those are both disabled? Once I did that the machine booted normally without the need to re-install.

I’ve tested on both a laptop and VM with the same issue.

However I just found a workaround on the VM. If I boot into the BIOS first, then exit and continue the boot process, the disk unlocks and the system starts!
But if I let the system boot directly into the OS, the disk does not unlock and I’m prompted for the recovery key.

I wonder if this is because when I installed the system, I first booted into the BIOS and then selected the installation media.

Did this on my test laptop and now everything is working as expected! Is this expected behaviour or a bug?