Bug 1001891 - [FEAT] surppot crypted kdump target
[FEAT] surppot crypted kdump target
Product: Fedora
Classification: Fedora
Component: kexec-tools (Show other bugs)
Unspecified Unspecified
medium Severity unspecified
: ---
: ---
Assigned To: arthur
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-08-28 00:24 EDT by Dave Young
Modified: 2014-03-10 05:18 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-03-10 05:18:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dave Young 2013-08-28 00:24:58 EDT
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:

Actual results:

Expected results:

Additional info:
Comment 1 arthur 2013-12-29 21:19:39 EST
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.

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!

Note You need to log in before you can comment on or make changes to this bug.