Bug 1451717 - kexec-tools tries to open encrypted drives
Summary: kexec-tools tries to open encrypted drives
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kexec-tools
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Xunlei Pang
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-17 11:01 UTC by Benjamin Berg
Modified: 2017-07-14 08:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-14 08:11:04 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


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