In case you are running Jammy and gets affected by this issue:
The workaround described consists of booting from a live usb, decrypting the disk, getting a chroot, and only then installing thin-provisioning-tools and running update-initramfs.
This is the script I was using to decrypt the disk and get the chroot (you will need to adjust it for your disk) [1].
In special, the name used with luksOpen should match the one described in /etc/crypttab
[1]:
#!/bin/bash
set -eux
sudo cryptsetup luksOpen /dev/nvme0n1p3 crypt_dev_nvme0n1p3
sudo vgscan --mknodes
sudo vgchange -ay
sudo mkdir /media/disk
sudo mount /dev/mapper/system-root /media/disk/
sudo mount /dev/nvme0n1p1 /media/disk/boot/
sudo cp -L /etc/resolv.conf /media/disk/etc/resolv.conf
cd /
sudo mount -t proc proc /media/disk/proc
sudo mount -t sysfs sys /media/disk/sys
sudo mount -o bind /dev /media/disk/dev
sudo chroot /media/disk /bin/bash
In case you are running Jammy and gets affected by this issue:
The workaround described consists of booting from a live usb, decrypting the disk, getting a chroot, and only then installing thin-provisioni ng-tools and running update-initramfs.
This is the script I was using to decrypt the disk and get the chroot (you will need to adjust it for your disk) [1].
In special, the name used with luksOpen should match the one described in /etc/crypttab
[1]:
#!/bin/bash system- root /media/disk/ disk/etc/ resolv. conf
set -eux
sudo cryptsetup luksOpen /dev/nvme0n1p3 crypt_dev_nvme0n1p3
sudo vgscan --mknodes
sudo vgchange -ay
sudo mkdir /media/disk
sudo mount /dev/mapper/
sudo mount /dev/nvme0n1p1 /media/disk/boot/
sudo cp -L /etc/resolv.conf /media/
cd /
sudo mount -t proc proc /media/disk/proc
sudo mount -t sysfs sys /media/disk/sys
sudo mount -o bind /dev /media/disk/dev
sudo chroot /media/disk /bin/bash