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 quietly breaks hardware enablement, in my case the webcam, with no supported way to fix it, without re-installing with play LUKS instead.
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 ended up on 24.04. I downloaded ubuntu-24.04.4-desktop-amd64.iso, ticked the encrypt-the-disk checkbox using TPM (I had to disable third-party drivers for that, that should have been the warning sign), 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 figure out why.
What’s actually in Dell’s OEM image
This story started by reverse-engineering the Dell OEM 22.04 Latitude_7450_Latitude_7650_Ubuntu_2204_A01_Recovery_image.iso recovery ISO, mostly because I was curious and wanted to see if Dell’s changes had mad it upstream, or if I really had to use the 22.04 Dell OEM image. In case of the latter, this would let me backport changes into 24.04 myself.
Mounting both images, the Dell ISO was 5.3 GB to vanilla’s 4.5 GB. Diffing the filesystem manifests showed what was filling the gap:
comm -13 \
<(awk '{print $1}' ".../Ubuntu 22.04.5 LTS amd64/casper/filesystem.manifest" | sort) \
<(awk '{print $1}' ".../Dell jellyfish-oddish X127/casper/filesystem.manifest" | sort)
The extra 800 MB was two things: a newer kernel for the Meteor Lake hardware, and a proprietary camera stack (interesting!). The 7450’s GPU, NPU, Wi-Fi 7, and IPU6 camera ISP were unsupported in 22.04’s stock 5.15 kernel, so Dell ships a backported 6.8 kernel with matching modules. The camera stack is Intel’s camera HAL, a virtual V4L2 device layer, and about thirty binary-only image-processing libraries. The rest was WWAN drivers and Dell tooling to wire it all together.
How much of this is in vanilla 24.04
Testing my 24.04 installation, most of it 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. 24.04 ships kernel 6.8, the same series Dell had to backport, so the iGPU, Wi-Fi, audio, fingerprint reader and Thunderbolt all worked, as if everything Dell contributed to 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 boot, and I knew 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. This looked similar to Ubuntu Core, actually a pretty cool immutable distro for embedded devices, but not what I thought I was installing for my normal Desktop use. Having installed Debian and Ubuntu dozens of times, I couldn’t figure out what I’d done differently.
A dead end on the snap side
Could I get the camera working anyway, staying on the snap kernel? The pre-built modules were out, 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.
The reinstall, and the plot twist
I reinstalled from the same ISO, this time choosing plain LUKS with a passphrase instead of TPM encryption. Then, before running a single line of the camera recipe, I checked:
$ 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 whole snap boot architecture I’d been fighting simply wasn’t there.
That sent me back to Canonical’s blog post about the TPM-FDE feature, which spells out 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. I can live with that.
What this leaves me with
The actual fix is nothing complicated: install with plain LUKS, let oem-somerville-oddish-meta do its job on first boot, add TPM auto-unlock with clevis afterwards.
The real problem was 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 picked up on it immediately. 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.
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.