Bug#901884: [cryptsetup-initramfs] Unbootable system with MODULES=dep
Le 20/06/2018 à 00:21, Guilhem Moulin a écrit : > On Tue, 19 Jun 2018 at 23:52:45 +0200, Guilhem Moulin wrote: >> Sorry, I meant between your backup initrd.img (presumably also compiled >> with MODULES=dep) and the new, broken one. > Alternatively, if you don't have this initrd around anymore, are you able > to boot if you add the ‘xts’ module to the broken one? > > echo xts >>/etc/initramfs-tools/modules > update-initramfs -u > systemctl reboot You were right. I diffed an old initramfs with a new one, and the only missing modules is xts. Since you already closed this issue, I don't have to test it anymore > (That's a lot of “ifs” and most systems won't be affected as default is > MODULES=most and these days AES-NI is common enough, so I'm not sure > ‘severity: critical’ is appropriate, but but it's definitely RC anyway.) Yes, that's how bug happens, with a lot of ifs :) I set it to critical because I had no idea if my system was the only affected or not. And yes, I have an old CPU… But it still fits my needs, and buying a new one will force me to buy everything else ;) I'm glad you take it seriously enough to publish a new version in less than 48h. Adrien
Bug#901884: [cryptsetup-initramfs] Unbootable system with MODULES=dep
On Tue, 19 Jun 2018 at 23:52:45 +0200, Guilhem Moulin wrote: > Sorry, I meant between your backup initrd.img (presumably also compiled > with MODULES=dep) and the new, broken one. Alternatively, if you don't have this initrd around anymore, are you able to boot if you add the ‘xts’ module to the broken one? echo xts >>/etc/initramfs-tools/modules update-initramfs -u systemctl reboot I'm now able to reproduce this in a test environment where the cipher mode (xts is your case) is provided by a separate module. We didn't catch that earlier because our test VMs run using their host's CPU model, which have AES-NI. Indeed, running qemu with `-cpu host,-aes` yields an unbootable system if the root FS is encrypted using AES-XTS and the initrd is compiled with MODULES=dep. (That's a lot of “ifs” and most systems won't be affected as default is MODULES=most and these days AES-NI is common enough, so I'm not sure ‘severity: critical’ is appropriate, but but it's definitely RC anyway.) -- Guilhem. signature.asc Description: PGP signature
Bug#901884: [cryptsetup-initramfs] Unbootable system with MODULES=dep
On Tue, 19 Jun 2018 at 23:00:29 +0200, Adrien CLERC wrote: > Le 19/06/2018 à 22:40, Guilhem Moulin a écrit : >> Could you run the following on both the broken and backup initrd and >> send the diff? >> >> lsinitramfs /path/to/initrd.img | grep ^lib/modules/ | sort > > See initramfs_dep_vs_most.diff.gz. The dep output is not working, and > the most output is working. Sorry, I meant between your backup initrd.img (presumably also compiled with MODULES=dep) and the new, broken one. -- Guilhem. signature.asc Description: PGP signature
Bug#901884: [pkg-cryptsetup-devel] Bug#901884: [cryptsetup-initramfs] Unbootable system with MODULES=dep
Le 19/06/2018 à 23:06, Guilhem Moulin a écrit : > Just noticed what looks like a regression, I wonder if that's the same > problem. Does your system have AES-NI or similar, or are you using the > generic modules? What's the output of > > grep -A2 '^name *: *xts(aes)' /proc/crypto > # grep -A2 '^name *: *xts(aes)' /proc/crypto name : xts(aes) driver : xts(ecb(aes-asm)) module : xts My CPU is Intel(R) Core(TM)2 Duo CPU E8400, so no, I don't have support for AES-NI in it. Adrien
Bug#901884: [cryptsetup-initramfs] Unbootable system with MODULES=dep
Le 19/06/2018 à 22:40, Guilhem Moulin a écrit :
> Could you run the following on both the broken and backup initrd and
> send the diff?
>
> lsinitramfs /path/to/initrd.img | grep ^lib/modules/ | sort
See initramfs_dep_vs_most.diff.gz. The dep output is not working, and
the most output is working.
> Also, please edit /usr/share/initramfs-tools/hooks/cryptroot and enable
> debuging withing populate_CRYPTO_MODULES:
>
> populate_CRYPTO_MODULES() {
> set -x
> […]
> set +x
> }
>
> Then run `update-initramfs -u` and attach the error output.
I wish you good luck, since the output (see update_initramfs_output.txt)
seems to be mixed, as if multiple tasks were running concurrently.
I try to run this multiple times to get a nicer output, without success.
> FWIW 2.0.3-2 was tested with MODULES=dep, too. I wonder how your system
> differs from our test environments.
OK, that's good news :)
initramfs_dep_vs_most.diff.gz
Description: application/gzip
+ local mod value cipher blockcipher ivhash
+ [ sda3_crypt = sda3_crypt ]
+ dmsetup table+ cut -d -f4
-- sda3_crypt
+ value=aes-xts-plain64
+ printf %s aes-xts-plain64
+ cut -d- -f1
+ cut -d: -f1
+ cipher=aes
+ [ -z aes ]
+ CRYPTO_MODULES=aes
+ printf %s aes-xts-plain64
+ cut -d- -f1
+ cut -d: -f1
+ blockcipher=aes
+ [ -n aes ]
+ [ aes != plain ]
+ CRYPTO_MODULES=aes aes
+ printf %s aes-xts-plain64
+ cut -d: -s -f2
+ ivhash=
+ [ -n ]
+ [ sda4_crypt = sda4_crypt ]
+ cut -d -f4
+ dmsetup table -- sda4_crypt
+ value=aes-xts-plain64
+ printf %s aes-xts-plain64
+ cut -d- -f1
+ cut -d: -f1
+ cipher=aes
+ [ -z aes ]
+ CRYPTO_MODULES=aes aes aes
+ printf %s aes-xts-plain64
+ cut -d- -f1
+ cut -d: -f1
+ blockcipher=aes
+ [ -n aes ]
+ [ aes != plain ]
+ CRYPTO_MODULES=aes aes aes aes
+ printf %s aes-xts-plain64
+ cut -d: -s -f2
+ ivhash=
+ [ -n ]
+ set +x
Bug#901884: [pkg-cryptsetup-devel] Bug#901884: [cryptsetup-initramfs] Unbootable system with MODULES=dep
On Tue, 19 Jun 2018 at 22:40:23 +0200, Guilhem Moulin wrote: > FWIW 2.0.3-2 was tested with MODULES=dep, too. I wonder how your system > differs from our test environments. Just noticed what looks like a regression, I wonder if that's the same problem. Does your system have AES-NI or similar, or are you using the generic modules? What's the output of grep -A2 '^name *: *xts(aes)' /proc/crypto -- Guilhem. signature.asc Description: PGP signature
Bug#901884: [cryptsetup-initramfs] Unbootable system with MODULES=dep
On Tue, 19 Jun 2018 at 21:39:06 +0200, Adrien CLERC wrote:
> Fortunately, the previous one has still a valid initramfs, so I can boot
> my system (many thanks for that backup system).
> […]
> Check that kernel supports aes-xts-plain64 cipher (check syslog for
> more info).
Could you run the following on both the broken and backup initrd and
send the diff?
lsinitramfs /path/to/initrd.img | grep ^lib/modules/ | sort
Also, please edit /usr/share/initramfs-tools/hooks/cryptroot and enable
debuging withing populate_CRYPTO_MODULES:
populate_CRYPTO_MODULES() {
set -x
[…]
set +x
}
Then run `update-initramfs -u` and attach the error output.
FWIW 2.0.3-2 was tested with MODULES=dep, too. I wonder how your system
differs from our test environments.
--
Guilhem.
signature.asc
Description: PGP signature
Bug#901884: [cryptsetup-initramfs] Unbootable system with MODULES=dep
Package: cryptsetup-initramfs Version: 2:2.0.3-2 Severity: critical --- Please enter the report below this line. --- Hi, I have a full disk-encryption set up with LUKS. After upgrading from 2.0.3-1 to 2.0.3-2 my last (and current) kernel is unbootable. Fortunately, the previous one has still a valid initramfs, so I can boot my system (many thanks for that backup system). Here are the log (copied manually): = Please unlock disk sda3_crypt: [ 14.107558] device-mapper: table: 253:0: crypt: Error allocating crypto tfm device-mapper: reload ioctl on failed: No such file or directory Failed to setup dm-crypt key mapping for device /dev/sda3. Check that kernel supports aes-xts-plain64 cipher (check syslog for more info). cryptsetup: ERROR: sda3_crypt: cryptsetup failed, bad password or options? Please unlock disk sda3_crypt: = Obviously, I cannot check the syslog for more info. But for now I don't want to run any update until I am sure I can boot the system. However, after setting MODULES from dep to most in /etc/initramfs-tools/initramfs.conf and re-generating the initramfs, the system can boot. Maybe the refactoring lost this feature, but I'd like to see it back, since it allows for faster initramfs generation, and kind of faster boot also. I'm available for some more tests if needed. Adrien --- System information. --- Architecture: Kernel: Linux 4.16.0-1-amd64 Debian Release: buster/sid 500 unstable ftp.fr.debian.org 500 testing download.jitsi.org 1 experimental ftp.fr.debian.org --- Package information. --- Depends (Version) | Installed ===-+-=== cryptsetup-run (>= 2:2.0.3-2) | 2:2.0.3-2 busybox | 1:1.27.2-2 OR busybox-static | initramfs-tools (>= 0.129) | 0.130 OR linux-initramfs-tool | Recommends (Version) | Installed -+-=== console-setup | 1.184 kbd | 2.0.4-3 Package's Suggests field is empty. --- Output from package bug script ---
