[Bug 2081700] Re: Can't boot from encrypted volume after initramfs-tools=0.142ubuntu25.3 update

[Benjamin Drung]

** 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
Foundations Bugs, 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:
  New

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