[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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
<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


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
Reply to: