Re: linux-image-4.9.0-12-amd64 breaks LUKS root
On Mon, 27 Jul 2020 at 09:47, David Christensen
<dpchrist@holgerdanske.com> 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
Reply to: