Bug 1001891

Summary:	[FEAT] surppot crypted kdump target
Product:	[Fedora] Fedora	Reporter:	Dave Young <ruyang>
Component:	kexec-tools	Assignee:	arthur <zzou>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	bhe, chaowang, kdump-team-bugs, ruyang, vgoyal
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-03-10 09:18:52 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Dave Young 2013-08-28 04:24:58 UTC

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:

Comment 1 arthur 2013-12-30 02:19:39 UTC

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!