** Description changed: + [ 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] + 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 + 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: + 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.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2081700 Title: Can't boot from encrypted volume after initramfs-tools=0.142ubuntu25.3 update To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2081700/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
