Bug 1451717

Summary:	kexec-tools tries to open encrypted drives
Product:	[Fedora] Fedora	Reporter:	Benjamin Berg <bberg>
Component:	kexec-tools	Assignee:	Xunlei Pang <xlpang>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	bhe, ruyang, xlpang
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-07-14 08:11:04 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:
Embargoed:

Description Benjamin Berg 2017-05-17 11:01:53 UTC

When using kdump on machines that are encrypted it is usually desirable to dump to an unencrypted target or network share) so that opening the LUKS device is not required. Unfortunately even when one configures it like this dracut tries to open the LUKS device and waits for the password to be entered.

Steps to reproduce:
1. Have a Fedora Workstation installation with encryption enabled
2. Change the dump target in /etc/kdump.conf to not point to the encrypted / partition (I used "ext4 /dev/sda1" which is /boot usually); create target directory as required
3. You might need to force the "drm" modules to be included
https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org/thread/I5YT5IRMFNNDFTJLIJOU442Z3GA4JU26/
4. Start kdump service
5. echo 1 >/proc/sys/kernel/sysrq
6. echo c >/proc/sysrq-trigger

Expected result:
* Crash dump dumped is created on specified (unencrypted partition)

Actual result:
* Image hangs during boot prompting for a password (though the prompt will be invisible at first).
* Password is entered
* Dumping proceeds normally after the password was provided

The original kernel commandline looks something like

BOOT_IMAGE=/vmlinuz-4.10.14-200.fc25.x86_64 crashkernel=256 root=/dev/mapper/fedora_ben--x1-root ro rd.lvm.lv=fedora_ben-x1/root rd.luks.uuid=luks-cd02d32e-e5d3-452b-8bf7-8a5abdc6320e rd.lvm.lv=fedora_ben-x1/swap rhgb quiet LANG=en_GB.UTF-8

an affected machines.

Note that adding "-o crypt" to dracut_args causes the dump to fail entirely (there is no password prompt and it reboots after failing to run a timeout script).

Comment 1 Xunlei Pang 2017-05-19 02:36:02 UTC

I'd like to take a look.

Comment 2 Xunlei Pang 2017-06-02 06:53:08 UTC

I am able to reproduce the issue now, the root cause is that:
The LUKS is over a normal disk, while the root fs lvm device is over LUKS,
that's why we got a dracut timeout(LVM timeout) when adding "dracut_args -o crypt" due to the LVM scan failure.

The correct workaround would be to remove lvm args(like rd.lvm.lv=rhel/root) along with "dracut_args -o "crypt"", if the dump target is not LUKS.

We need some discussion about the proper fix in code.