Additionally, did a full `apt-get update && apt-get upgrade && reboot` just in case. Everything is working
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2081700 Title: Can't boot from encrypted volume after initramfs-tools=0.142ubuntu25.3 update Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Noble: Fix Committed Bug description: [ Impact ] # Expected After an update to `initramfs-tools` from 0.142ubuntu25.2 to 0.142ubuntu25.3 I can boot my system from an encrypted root volume. # What happened instead After an update to `initramfs-tools` from 0.142ubuntu25.2 to 0.142ubuntu25.3, I could no longer boot my system. The error I was getting is this after entering the correct password: ``` device-mapper: table: 252:0: crypt: unknown target type device-mapper: ioctl: error adding target to table device-mapper: reload ioctl on test (252:0) failed: Invalid argument ``` I managed to add set -x to the initramfs scripts, which showed me the command it uses that leads to this error: ``` /sbin/cryptsetup -T1 --allow-discards '--type=luks' '--key-file=-' open -- /dev/nvme0n1p3 test ``` And my `/etc/crypttab` looks like this: ``` test UUID=9a6218aa-6e36-4f0d-8567-770af1274240 none luks,discard ``` I also tried to add "break" to the kernel line and set up luks manually via the initramfs shell, which led to the same error. After quite a significant amount of time randomly trying to load modules without success, I decided to check what had changed after my last successful boot in terms of packages. One of the few upgrades was the one mentioned at the beginning. So I downgraded `initramfs-tools` back to 0.142ubuntu25.2, it regenerated the image, and the system booted successfully. Below you can find additional data about my setup. I use an LVM setup on top of a luks-encrypted volume. Here is the overall layout: ``` /dev/nvme0n1p2 on /boot type ext4 /dev/nvme0n1p1 on /boot/efi type vfat ``` Here is the data about my luks setup: ``` # cryptsetup luksDump /dev/nvme0n1p3 <...skipped...> Data segments: 0: crypt offset: 16777216 [bytes] length: (whole device) cipher: aes-xts-plain64 sector: 512 [bytes] Keyslots: 0: luks2 Key: 512 bits Priority: normal Cipher: aes-xts-plain64 Cipher key: 512 bits PBKDF: argon2id <...skipped...> ``` Link to the changes in the broken version of the package: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/0.142ubuntu25.3 Kernel versions I tried it with: 6.8.0-44-generic and 6.8.0-45-generic OS: Ubuntu 24.04.1 LTS [ Test Plan ] Same as bug #2081334: 1. Measure `update-initramfs -u` before the update. 2. Log the content of the initrd before the update: `lsinitramfs /boot/initrd.img` 3. update dracut-install / initramfs-tools-core 4. Measure `update-initramfs -u`. It should be faster (the performance improvements on amd64 should be very small and might be within the measurement uncertainty). 5. Check with lsinitramfs that the content of the newly generated initrd hasn't changed. Do this test on a system which uses encryption. [ Where problems could occur ] The code that is responsible for including the kernel modules into the initrd is touched. Negative consequences could be that some needed kernel modules will not be included any more (should be covered by the test case) or that building new initrds will fail. The initramfs-tools fix changes how manual_add_modules behaves. `manual_add_modules` does not copy kernel modules, but queues them for being copied when the newly added function `apply_add_modules` is called. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2081700/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
