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
2 Likes
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?
Hi,
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.
Questions:
- 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.
Best
Keywan
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:
linux-headers-6.5.0-10-generic
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:
/var/cache/apt/archives/linux-headers-6.5.0-10-generic_6.5.0-10.10_amd64.deb
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:
-
sudo apt clean && sudo apt update && sudo apt upgrade -
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:
linux-headers-6.5.0-10-generic
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:
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.
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?