rpms/kexec-tools
6
0
Fork 0
Code Issues Pull Requests Releases Activity

Limit LUKS support to x86_64

Browse Source 
Resolves: https://issues.redhat.com/browse/RHEL-104940
Conflict: None

commit 4094199402119ad4f97d073b40a35d890754dc8e
Author: Coiby Xu <coxu@redhat.com>
Date:   Wed Sep 17 08:57:30 2025 +0800

    Limit LUKS support to x86_64

    The LUKS support depends on the kernel but only x86_64 kernel part is
    ready. So limit this feature to x86_64.

    And don't fail kdump.service even when x86_64 kernel doesn't have
    /sys/kernel/config/crash_dm_crypt_keys in case users have already
    manually made dumping to encrypted target work.

    Signed-off-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
This commit is contained in:
Coiby Xu 2025-10-09 16:52:06 +08:00
parent 10253d9e05
commit 4d9c3d6fd1
5 changed files with 34 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
dracut-module-setup.sh
View File

@ -1149,6 +1149,9 @@ kdump_check_crypt_targets() {
local _devuuid _key_desc
declare -a _luks_devs
# Currently only x86_64 is supported
[[ "$(uname -m)" != "x86_64" ]] && return 1
mapfile -t _luks_devs < <(get_all_kdump_crypt_dev)
if [[ ${#_luks_devs[@]} -lt 1 ]]; then

15
kdumpctl
View File

@ -1102,9 +1102,15 @@ prepare_luks()
return
fi
# Currently only x86_64 is supported
if [[ "$(uname -m)" != "x86_64" ]]; then
dwarn "Warning: Encrypted device is in dump path, which is not recommended, see kexec-kdump-howto.txt for more details."
return 0
fi
if [[ ! -d $LUKS_CONFIGFS ]]; then
dwarn "$LUKS_CONFIGFS not available, please use a newer kernel."
return 1
dwarn "$LUKS_CONFIGFS not available, please use a newer kernel or see kexec-kdump-howto.txt to make sure dumping to encrypted target will work."
return 0
fi
# For the case of CPU/memory hotplugging, we can reuse loaded keys
@ -1192,6 +1198,11 @@ setup_crypttab()
local _devuuid uuids_string temp_file
declare -a _luks_devs
if [[ "$(uname -m)" != "x86_64" ]]; then
dwarn "Currently only x86_64 supported"
return 0
fi
if [[ ! -f $CRYPTTAB_FILE ]]; then
dinfo "$CRYPTTAB_FILE doesn't exist, skip setup"
return 0

8
kdumpctl.8
View File

@ -83,9 +83,11 @@ LUKS-encrypted disk volume. For more info on link-volume-key option,
please "man crypttab".
This step is optional. If kdump.service can start successfully, there is no
need for this step. You can confirm if this step is needed by running "kdumpctl
restart". If you need to input any passpharse to unlock the the encrypted
volume, please run "kdumpctl setup-crypttab".
need for this step. You can confirm if this step is needed by running
"kdumpctl restart". If you need to input any passpharse to unlock the the
encrypted volume, then please run "kdumpctl setup-crypttab".
Note this subcommand is only helpful to x86_64 for now.
.SH "SEE ALSO"
.BR kdump.conf (5),

17
kexec-kdump-howto.txt
View File

@ -882,16 +882,23 @@ or else kdump may not work as expeceted.
Notes on encrypted dump target
------------------------------
Currently, kdump is not working well with encrypted dump target.
First, user have to give the password manually in capture kernel,
so a working interactive terminal is required in the capture kernel.
Currently, only x86_64 supports encrypted dump target. And depending on
your setup, you may need to run "kdumpctl setup-crypttab" once in order
for kdump.service to work on boot automatically next time. You can
confirm if this step is needed by running "kdumpctl restart". If you have
to input passphrase to unlock the encrypted volume, then please run
"kdumpctl setup-crypttab".
For other architectures, kdump is not working well. First, user have
to give the password manually in capture kernel, so a working
interactive terminal is required in the capture kernel.
And another major issue is that an OOM problem will occur with certain
encryption setup. For example, the default setup for LUKS2 will use a
memory hard key derivation function to mitigate brute force attach,
it's impossible to reduce the memory usage for mounting the encrypted
target. In such case, you have to either reserved enough memory for
crash kernel according, or update your encryption setup.
It's recommanded to use a non-encrypted target (eg. remote target)
crash kernel accordingly, or update your encryption setup.
It's recommended to use a non-encrypted target (eg. remote target)
instead.
Notes on device dump

2
supported-kdump-targets.txt
View File

@ -49,7 +49,7 @@ storage:
NVMe-FC (qla2xxx, lpfc)
NVMe/TCP configured by NVMe Boot Firmware Table (users may need to
increase the crashkernel value)
LUKS-encrypted volume
LUKS-encrypted volume (only x86_64 supported for now)
network:
Hardware using kernel modules: (igb, ixgbe, ice, i40e, e1000e, igc,