kdump does not work with encrypted root partition

[KDEUSER56]

I have my root partition encrypted using dm-crypt.
I could not get kdump working with the encrypted root partition, the computer simply hangs forever and will never reboot. (I tried the same kdump and grub settings on an identical install without encrypted root on the same machine and everything worked fine there.)

No errors are shown on the screen, when I trigger a panic from an x session since the display is simply frozen and nothing will happen. I guess the crash kernel expects the luks password and therefore will wait for the password forever. I tried to blindly type in my password, but I have never succeeded.

I can imagine 2 ways this bug could be solved:

1.) the password for the root partition could be passed from the primary kernel to the crash kernel during load time
This is discussed here: https://bugzilla.redhat.com/show_bug.cgi?id=1028397 in comment #9:
"One could argue that password could be passed to second kernel in bootparams
during load time. But this is very unconventional and first requires the work
I am doing to implement a new kexec syscall which prepares bootparam in kernel (as opposed to user space).
So in long term may be there is a case that pass credentials from old kernel to new kernel using bootparams. But don't expect anything soon."

2.) kdump allows dumping to an external partition that is not encrypted without mounting the root partition, such as the /boot partition.

Another redhat bug report where something similar is discussed: https://bugzilla.redhat.com/show_bug.cgi?id=1053045.

[Louis Bouchard (louis)]

Hello,

Unlike Fedora, Debian and ubuntu kernel dump mechanism is installed on the root filesystem and not in the initrd. So in order to be able to run kdump, the root filesystem needs to be mounted first.

This is handled by the /scripts/local-top/cryptroot script which is where the prompt for the passphrase happens. So the kdump-tools scripts have no way to interact with that phase of the boot. There is no kernel argument to the cryptroot script that would allow it to receive a passphrase when the second kernel is booted.

Using the cryptkeyscript / cryptkey boot parameters to pass a keyfile to open the encrypted root would create major security issue so it is not viable.

So kexec-tools has no solution for this issue as it lies outside of its control.