TL;DR: Rediscovering that on Ubuntu 24.04 and 26.04, ticking “Use hardware-backed disk encryption” in the installer silently gives you a snap-based system (snap kernel and bootloader, like Ubuntu Core) instead of a normal deb-based one. On a modern laptop, this can breaks hardware enablement, in my case the webcam, with no supported way to fix it or have an equivalent feature set.
I got my hands on a Dell Latitude 7450, certified with Ubuntu 22.04 (this Ubuntu blog post on the certification process is worth a read), and decided to try a newer LTS version. Ubuntu 26.04 was out but really new, so I decided to start with 24.04. I downloaded the ISO, ticked the disk encryption checkbox using TPM (I had to disable third-party drivers for that), and found myself with a system where the camera was not working.
In the past, I never had a flawless experience using Ubuntu on a laptop, but those were from non-certified machines. The Latitude 7450 had Canonical’s blessing, so what was going on? Surprisingly, reinstalling with the same ISO and ticking a different encryption checkbox (LVM with passphrase) makes the camera work out of the box.
Let’s try to figure out what happened.
Discovering the issue in vanilla 24.04
Initially, on my 24.04 installation, most just worked out-of-the-box. Ubuntu installed a meta package oem-somerville-oddish-meta (“Somerville” is Dell’s OEM program, “Oddish” the codename for this laptop, yes like the Pokémon), adding Dell’s apt archive to my sources, so I was confident about compatibility. After verifications the iGPU, Wi-Fi, audio, fingerprint reader and Thunderbolt all worked. It seemed the work Dell did building their Latitude_7450_Latitude_7650_Ubuntu_2204_A01_Recovery_image.iso 22.04 had since moved upstream, good job!
Except…
The camera doesn’t work, and nothing can fix it
The webcam was the obvious omission, with no /dev/video* at all. The hardware was fine (the laptop was new, and lsusb showed the chip). dkms status listed the IPU6 camera modules as registered but never built. Searching the internet, the recipe for this exact problem was: install the pre-built camera modules from Dell’s archive instead of the DKMS ones, add v4l2-relayd, reboot, done. Surprise surprise, it did not install:
$ sudo apt install linux-modules-ipu6-generic ...
linux-modules-ipu6-6.8.0-111-generic : Depends: linux-image-6.8.0-111-generic but it is not going to be installed
The modules need a kernel image to attach to. Alright, let’s get that kernel image:
$ sudo apt install linux-image-6.8.0-111-generic linux-modules-ipu6-generic ...
boot-managed-by-snapd : Conflicts: linux-image, grub-efi-amd64, grub-pc,
linux-firmware, shim-signed ...
Oh no.
My kernel is a snap!
I was taken aback, what did boot-managed-by-snapd mean? I knew the word boot, and I knew the word snap, but a snap-managed boot? It was conflicting with linux-image, GRUB, shim, linux-firmware, basically everything Debian-based systems use to boot.
$ cat /proc/cmdline
snapd_recovery_mode=run console=tty1 ...
$ snap list | grep pc-kernel
pc-kernel 6.8.0-110.110 3374 24/stable canonical✓ kernel
$ dpkg -l | grep linux-image
(no output)
$ ls /boot/efi
ls: cannot access '/boot/efi': No such file or directory
There was no deb kernel, no /boot/efi. My kernel was a snap, and I didn’t know what to make of it. After some research, I learned about Ubuntu Core, actually a pretty cool immutable distro for embedded devices, but this was not what I thought I was installing for my normal laptop use. Having installed Debian and Ubuntu dozens of times, I couldn’t figure out what I’d done differently.
A dead end with the camera on the snap side
Could I get the camera working anyway, staying on the snap kernel? The pre-built modules were there, so that left building them with DKMS. They built fine, but would not load:
$ sudo modprobe intel_ipu6
modprobe: ERROR: could not insert 'intel_ipu6': Key was rejected by service
Secure Boot, which TPM-FDE requires, refused unsigned modules. To sign my own I’d need to enroll a key, which changes PCR 7, which is what the TPM is using for decryption. I could recover from that with the recovery key, but the documentation is blunt about the side-effect: “On subsequent boots, you have to continue using your recovery key.” There’s no supported way to reconverge after that. On this kernel, I was hitting a dead end for the camera.
I still didn’t know why the camera was missing in the first place, so I decided to reinstall without TPM encryption, giving me a chance to disable Secure Boot and try again.
Reinstalling: plot twist
I reinstalled from the same ISO, this time choosing plain LUKS with a passphrase instead of TPM encryption. Then, before running any single command on my system, I checked the camera again:
$ ls /dev/video*
*49 entries*
Amazingly, the camera was working. cheese showed my face. I’d done nothing. What had changed?
The first thing I noticed was the kernel. uname -r showed a plain deb HWE kernel, and boot-managed-by-snapd was gone. The snap kernel was gone, good job me! I felt like my dog when I congratulate him: he feels very happy, but I’m pretty sure he doesn’t always know what he’s done.
That sent me back to Canonical’s blog post about the TPM-FDE feature, which describes what the checkbox actually does: “TPM-backed FDE: this will install a classic desktop system that gets its kernel and bootloader assets from snaps. Non TPM-backed FDE: this will install an entirely deb-based classic desktop system.” So one checkbox silently chooses between two architecturally different operating systems. Ubuntu has decided, for better or worse, that TPM encryption requires their snap-managed kernel.
That single difference explained the working camera. On a deb system, oem-somerville-oddish-meta is more than a stub pointing to a remote archive: once it adds the Dell archive, apt finds a higher-versioned package of the same name inside that archive, and that one pulls the HWE kernel and the camera stack. So the entire Latitude 7450 hardware stack works out-of-the-box on 24.04, zero effort required. On snap, it can’t, because the Dell OEM package depends on the linux-image deb, nowhere to be found in a snap environment.
Getting the TPM auto-unlock anyway, without snap
I still wanted the laptop to unlock itself without snap’s arcane machinery. A systemd-cryptenroll route I found online looked right but didn’t work, because Ubuntu’s initramfs uses the older Debian cryptsetup wrapper that silently ignores the TPM option. Fortunately, one of my favorite Linux tools came to the rescue: clevis.
sudo apt install clevis-luks clevis-tpm2 clevis-initramfs
sudo clevis luks bind -d /dev/nvme0n1p3 tpm2 '{"pcr_bank":"sha256","pcr_ids":"7"}'
sudo update-initramfs -u
While I had to wipe the first systemd-cryptenroll attempt, this otherwise worked flawlessly. The only minor drawback is the decryption password prompt showing for a few seconds at boot before the auto-unlock kicks in. The only major drawback is that it doesn’t bring the same security benefits as TPM-backed full disk encryption… Perhaps readers know of a better way, perhaps by enrolling a Secure Boot key before TPM locks it in?
What this leaves me with
No real fixes and a workaround: install with plain LUKS, and let oem-somerville-oddish-meta do its job on first boot. Will I feel like I achieved something, I still lost the security benefits that come with decrypting on user login, our clevis implementation is but a pale imitation of what TPM enables. This, or I had to enter my recovery key on every boot, defeating the purpose.
The real problem is the snap-managed kernel hiding behind a single checkbox with major consequences one may quickly forget about. Someone who doesn’t toggle third-party drivers on for any reason may never see the warning, then hit issues weeks or months later when those drivers may be wanted or needed. One installer was outputting two different operating systems.
Looking back, none of this was a surprise. When Canonical announced the feature, online communities immediately picked up on it. On LWN, user mfuzzey prophesied:
I suspect there is a significant subset of users who would like TPM based FDE for the security benefits but would prefer to stay with DEBs.
On Hacker News, the top comment by michaelt about Ubuntu’s blog post went further:
And there it is. I suppose having your kernel command line signed by Canonical and unmodifiable by the system owner without a pain-in-the-ass manual ‘machine owner key enrolment’ process is very much on-brand for Snap.
It only took me several hours to rediscover what these readers had warned about three years ago. I can accept Canonical restricting features behind their snap kernel, but I wish they had done a better job at informing users about their installer’s option. If you’re setting up a modern laptop with Ubuntu, know what choosing TPM-FDE actually means.
Dell Latitude 7450 configured with an Intel Core Ultra 7 165U CPU and Hynix HI-556 camera sensor.