Description of problem: Currently kdump do not support crypted target, we need to check if it's possible to use key instead of interactive method to activate crypted volumes. If it's ok then we can add the crypted target to our support list. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Hi Dave Currently systemd don't support decrypt a luks partion with key in a removeable device. Here is the details. Yes, systemd understands the kernel command line parameters "rd.luks.key=" and this can help systemd ecrypt a luks partion. But what the key point is the semanteme of "rd.luks.key=" is different between systemd and init script in dracut. In systemd, the syntax is rd.luks.key=<keypath>. That means if the rootfilesystem is encrypted. the keyfile must reside in initramfs so that systemd can find it. What's more, this make systemd can support decrypt a luks partion with key in a removeable device because the removeable device should be mounted first so that systemd can find the keyfile by path. Unlike systemd, In init, the syntax is rd.luks.key=<keypath>:<keydev>:<luksdev>. keypath is a path to key file to look for. It’s REQUIRED. keydev is a device on which key file resides. If luksdev is given, the specified key will only be applied for that LUKS device. The follow link has also mentioned a similar problem. https://bugzilla.redhat.com/show_bug.cgi?id=905683 In summary, if you want to decrypt a luks partion with key in a removeable device you should use init instead of systemd to be first process. You can achieve this by using "dracut -o "systemd" -f " to generate a new initramfs with init script in it. But in kdump, since we have moved to systemd. I think we had better wait systemd to support decrypt a luks partion with key in a removeable device. Thank you!