2

Issue

kdump.service fails to start on CentOS 8 virtual machine on Google Cloud. Restarting the service keeps reproducing the same error.

It seems the secure boot is causing the issue or is at least related to it. Required key cannot be loaded.

The solution for CentOS 7 does not solve the issue. Packages kexec-tools, crash , and kernel-debug are installed.

How do I solve this issue? Thank you.

Below are technical details.

Environment

  • CentOS 8 virtual machine instance on Google Cloud
  • OS version: CentOS Linux release 8.2.2004 (Core)
  • Kernel version: 4.18.0-193.19.1.el8_2.x86_64

Details

systemctl status kdump.service outputs:

kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2020-10-19 23:18:32 UTC; 2min 2s ago
  Process: 131082 ExecStart=/usr/bin/kdumpctl start (code=exited, status=1/FAILURE)
 Main PID: 131082 (code=exited, status=1/FAILURE)

Oct 19 23:18:28 my_hostname systemd[1]: Starting Crash recovery kernel arming...
Oct 19 23:18:32 my_hostname kdumpctl[131082]: Secure Boot is enabled. Using kexec file based syscall.
Oct 19 23:18:32 my_hostname kdumpctl[131082]: kexec_file_load failed: Required key not available
Oct 19 23:18:32 my_hostname kdumpctl[131082]: kexec: failed to load kdump kernel
Oct 19 23:18:32 my_hostname kdumpctl[131082]: Starting kdump: [FAILED]
Oct 19 23:18:32 my_hostname systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE
Oct 19 23:18:32 my_hostname systemd[1]: kdump.service: Failed with result 'exit-code'.
Oct 19 23:18:32 my_hostname systemd[1]: Failed to start Crash recovery kernel arming.

journalctl -xe outputs:

Oct 19 23:18:32 my_hostname kdumpctl[131082]: Secure Boot is enabled. Using kexec file based syscall.
Oct 19 23:18:32 my_hostname kdumpctl[131082]: kexec_file_load failed: Required key not available
Oct 19 23:18:32 my_hostname kdumpctl[131082]: kexec: failed to load kdump kernel
Oct 19 23:18:32 my_hostname kdumpctl[131082]: Starting kdump: [FAILED]
Oct 19 23:18:32 my_hostname systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE
Oct 19 23:18:32 my_hostname systemd[1]: kdump.service: Failed with result 'exit-code'.
Oct 19 23:18:32 my_hostname systemd[1]: Failed to start Crash recovery kernel arming.
-- Subject: Unit kdump.service has failed
-- Defined-By: systemd
-- Support: https://access.redhat.com/support
--
-- Unit kdump.service has failed.
--
-- The result is failed.
Oct 19 23:18:32 my_hostname sudo[131078]: pam_unix(sudo:session): session closed for user root

cat /proc/keys outputs:

00e8d728 I--Q---    14 perm 3f030000  1002    10 keyring   _ses: 1
029d6be0 I--Q---     1 perm 1f3f0000  1002 65534 keyring   _uid_ses.1002: 1
321674d8 I--Q---    11 perm 3f030000  1002    10 keyring   _ses: 1
37bb77f9 I--Q---     3 perm 1f3f0000  1002 65534 keyring   _uid.1002: empty
3b9154f0 I--Q---     8 perm 3f030000  1002    10 keyring   _ses: 1

rpm -q kexec-tools outputs:

kexec-tools-2.0.20-14.el8.x86_64
Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
Skyler
  • 21
  • 1
  • 3
  • 1
    I've run into the same issue with CentOS 7. The link for CentOS 7 isn't applicable as I'm getting the `Required key cannot be loaded.` error versus `No memory reserved for crash kernel.` I did see the following link indicates a solution https://access.redhat.com/solutions/3683241 but I'm not a RedHat subscriber. Looking forward to an answer on this one. – duct_tape_coder Oct 22 '20 at 21:13
  • Thank you. I saw that Red Hat forum post as well. I think there is another one on Red Hat. But I'm not a subscriber, either. Yesterday, I tried to enrolled the MOK key and rebooted the system. Then I completely messed up my system. – Skyler Oct 22 '20 at 21:22
  • Because my CentOS 8 is actually running in the cloud, I use an SSH connection. But after rebooting the system, I couldn't connect to it via SSH. I think the kernel could not be loaded. The system was stuck at the MOK enrollment interface during booting. I couldn't SSH into it because the kernel wasn't loaded yet. – Skyler Oct 22 '20 at 21:24
  • Since then I have downloaded the virtual machine image from the cloud and run it locally. The system couldn't be booted correctly, so I used a live CD to boot into it and repaired the boot loader. The MOK key might have been enrolled. The kdump.service is operational now, in my local virtual environment. Nevertheless, I'm not exactly sure what happened. – Skyler Oct 22 '20 at 21:27
  • I'm going to put the repaired virtual machine image back to the cloud and run it. We'll see what happens. – Skyler Oct 22 '20 at 21:28
  • In retrospect, after I enrolled the MOK key, but before rebooting, I was expecting that the system might be stuck at booting, and I would need to hardwire a display to the machine to finish the MOK key enrollment. But I rebooted it anyway. That was stupid. – Skyler Oct 22 '20 at 21:30
  • 1
    The lessons I learned are: (1) take a snapshot of the virtual machine before doing anything dangerous. (2) don't experiment on the live server. Download a copy of the virtual machine and play with it locally. – Skyler Oct 22 '20 at 21:32

0 Answers0