Bug#955329: linux-image-4.9.0-12-amd64 breaks LUKS root
On 2020-07-26 18:15, David wrote: On Mon, 27 Jul 2020 at 09:47, David Christensen wrote: On 2020-03-30 02:58, deloptes wrote: David Christensen wrote: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955329 I updated/ upgraded the system today and whatever broke LUKS when I 'apt-get dist-upgrade' and installed kernel 4.9.0-12-amd64 several months ago now breaks LUKS when I try to boot the kernel that I have been using prior and since -- 4.9.0-11-amd64. Fortunately, LUKS still works with my oldest available kernel, 4.9.0-9-amd64. lsinitramfs will give you the content of the initrd Any other suggestions? Hi, just a few thoughts from a dumb onlooker ... I notice that your bug 955329 is filed against the linux-image package around 4 months ago, and that there has been no reply from the maintainers. Looking around for similar bugs, I found [1] this comment by one of the maintainers: LUKS volumes are recognised and set uo by userland, so are you sure this is due to the kernel upgrade? So maybe it's not helpful to focus on the kernel, and I wonder if you would get a response or debugging assistance if you were to report this against the cryptsetup-initramfs package. Another suggestion, although I am far from an expert in these matters, I wonder if (per man initramfs-tools) you have tried using a kernel boot parameter 'break=premount' and then see what happens if you try to run your cryptsetup command in the initramfs shell. For example, I would try: (initramfs) blkid (initramfs) cryptsetup open /dev/whatever/blkid/says somename (initramfs) blkid and expect to see /dev/mapper/somename in the output of the last command if it succeeds, or some clue if it does not. You can also run commands like (initramfs) mount (initramfs) ls (initramfs) cat /cryptroot/crypttab to investigate further. I confirm all these commands do work for me on a Debian 10 machine. Also, if that fails, it might be useful to confirm that the drive can be decrypted when temporarily connected to another working system. Hope this helps. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827342#10 Thanks for the suggestions. Given the motherboard is circa 2011, Debian 9 has reached end of maintenance, and the lack of response on my initial bug report, I doubt this bug will be fixed. Even if I had some success in debugging the issue and submitted reports and/or patches, I don't know if or what the Debian project would do with them. It's time to put in a fresh system drive and try something newer that is actively supported. David
Bug#955329: linux-image-4.9.0-12-amd64 breaks LUKS root
On Mon, 27 Jul 2020 at 09:47, David Christensen wrote: > On 2020-03-30 02:58, deloptes wrote: > > David Christensen wrote: > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955329 > > I updated/ upgraded the system today and whatever broke LUKS when I > 'apt-get dist-upgrade' and installed kernel 4.9.0-12-amd64 several > months ago now breaks LUKS when I try to boot the kernel that I have > been using prior and since -- 4.9.0-11-amd64. Fortunately, LUKS still > works with my oldest available kernel, 4.9.0-9-amd64. > > > lsinitramfs will give you the content of the initrd > > Any other suggestions? Hi, just a few thoughts from a dumb onlooker ... I notice that your bug 955329 is filed against the linux-image package around 4 months ago, and that there has been no reply from the maintainers. Looking around for similar bugs, I found [1] this comment by one of the maintainers: > LUKS volumes are recognised and set uo by userland, so are you sure > this is due to the kernel upgrade? So maybe it's not helpful to focus on the kernel, and I wonder if you would get a response or debugging assistance if you were to report this against the cryptsetup-initramfs package. Another suggestion, although I am far from an expert in these matters, I wonder if (per man initramfs-tools) you have tried using a kernel boot parameter 'break=premount' and then see what happens if you try to run your cryptsetup command in the initramfs shell. For example, I would try: (initramfs) blkid (initramfs) cryptsetup open /dev/whatever/blkid/says somename (initramfs) blkid and expect to see /dev/mapper/somename in the output of the last command if it succeeds, or some clue if it does not. You can also run commands like (initramfs) mount (initramfs) ls (initramfs) cat /cryptroot/crypttab to investigate further. I confirm all these commands do work for me on a Debian 10 machine. Also, if that fails, it might be useful to confirm that the drive can be decrypted when temporarily connected to another working system. Hope this helps. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827342#10
Bug#955329: linux-image-4.9.0-12-amd64 breaks LUKS root
On 2020-03-30 02:58, deloptes wrote: David Christensen wrote: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955329 I updated/ upgraded the system today and whatever broke LUKS when I 'apt-get dist-upgrade' and installed kernel 4.9.0-12-amd64 several months ago now breaks LUKS when I try to boot the kernel that I have been using prior and since -- 4.9.0-11-amd64. Fortunately, LUKS still works with my oldest available kernel, 4.9.0-9-amd64. lsinitramfs will give you the content of the initrd I was unable to understand your other suggestions, but tried to use this one: 2020-07-26 16:35:36 root@po ~ # lsinitramfs -l /boot/initrd.img-4.9.0-9-amd64 > lsinitramfs-l-initrd.img-4.9.0-9-amd64.out 2020-07-26 16:35:57 root@po ~ # lsinitramfs -l /boot/initrd.img-4.9.0-11-amd64 > lsinitramfs-l-initrd.img-4.9.0-11-amd64.out The listings are very large: 2020-07-26 16:40:08 root@po ~ # wc lsinitramfs-l-initrd.img-4.9.0-* 1243 11247 128364 lsinitramfs-l-initrd.img-4.9.0-11-amd64.out 1243 11247 127485 lsinitramfs-l-initrd.img-4.9.0-9-amd64.out 2486 22494 255849 total And there are a lot of changes: 2020-07-26 16:40:50 root@po ~ # diff lsinitramfs-l-initrd.img-4.9.0-9-amd64.out lsinitramfs-l-initrd.img-4.9.0-11-amd64.out | grep '>' | wc 9779878 112569 2020-07-26 16:40:52 root@po ~ # diff lsinitramfs-l-initrd.img-4.9.0-9-amd64.out lsinitramfs-l-initrd.img-4.9.0-11-amd64.out | grep '>' | head > drwxr-xr-x 10 root root0 Jul 26 15:46 . > drwxr-xr-x 3 root root0 Jul 26 15:46 conf > drwxr-xr-x 2 root root0 Jul 26 15:46 conf/conf.d > -rw-r--r-- 1 root root 76 Jul 26 15:46 conf/conf.d/cryptroot > -rw-r--r-- 1 root root 16 Jul 26 15:46 conf/arch.conf > drwxr-xr-x 2 root root0 Jul 26 15:46 sbin < lrwxrwxrwx 1 root root 12 Jan 9 2020 sbin/mount.ntfs -> /bin/ntfs-3g > lrwxrwxrwx 1 root root 12 Jul 26 15:46 sbin/mount.ntfs -> /bin/ntfs-3g < lrwxrwxrwx 1 root root 12 Jan 9 2020 sbin/mount.ntfs-3g -> /bin/ntfs-3g > lrwxrwxrwx 1 root root 12 Jul 26 15:46 sbin/mount.ntfs-3g -> /bin/ntfs-3g I doubt I can find the needle(s) in that haystack. Any other suggestions? David
