Description of problem: $ sudo systemctl start kdump Job for kdump.service failed because the control process exited with error code. See "systemctl status kdump.service" and "journalctl -xe" for details. $ sudo journalctl -xe 7月 14 16:48:31 X1 dracut[14008]: lrwxrwxrwx 1 root root 11 Nov 7 2016 var/lock -> ../run/lock 7月 14 16:48:31 X1 dracut[14008]: lrwxrwxrwx 1 root root 6 Nov 7 2016 var/run -> ../run 7月 14 16:48:31 X1 dracut[14008]: drwxr-xr-x 1 root root 0 Nov 7 2016 var/tmp 7月 14 16:48:31 X1 dracut[14008]: ======================================================================== 7月 14 16:48:31 X1 dracut[14008]: *** Creating initramfs image file '/boot/initramfs-4.11.9-200.fc25.x86_64kdump.img' do 7月 14 16:48:32 X1 kdumpctl[11950]: Secure Boot is enabled. Using kexec file based syscall. 7月 14 16:48:32 X1 kdumpctl[11950]: kexec_file_load failed: Required key not available 7月 14 16:48:32 X1 kernel: PKCS#7 signature not signed with a trusted key 7月 14 16:48:32 X1 kdumpctl[11950]: kexec: failed to load kdump kernel 7月 14 16:48:32 X1 kdumpctl[11950]: Starting kdump: [FAILED] 7月 14 16:48:32 X1 systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE 7月 14 16:48:32 X1 systemd[1]: Failed to start Crash recovery kernel arming. -- Subject: kdump.service 单元已失败 -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- kdump.service 单元已失败。 -- -- 结果为“failed”。 7月 14 16:48:32 X1 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kdump comm="systemd" exe 7月 14 16:48:32 X1 systemd[1]: kdump.service: Unit entered failed state. 7月 14 16:48:32 X1 systemd[1]: kdump.service: Failed with result 'exit-code'. 7月 14 16:48:32 X1 sudo[11947]: pam_unix(sudo:session): session closed for user root 7月 14 16:48:32 X1 audit[11947]: USER_END pid=11947 uid=0 auid=1000 ses=2 msg='op=PAM:session_close grantors=pam_keyinit 7月 14 16:48:32 X1 audit[11947]: CRED_DISP pid=11947 uid=0 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_env,pam_fpri 7月 14 16:48:37 X1 sudo[21024]: derek : TTY=pts/1 ; PWD=/home/derek ; USER=root ; COMMAND=/bin/journalctl -xe 7月 14 16:48:37 X1 audit[21024]: USER_CMD pid=21024 uid=1000 auid=1000 ses=2 msg='cwd="/home/derek" cmd=6A6F75726E616C63 7月 14 16:48:37 X1 audit[21024]: CRED_REFR pid=21024 uid=0 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_env,pam_fpri 7月 14 16:48:37 X1 sudo[21024]: pam_systemd(sudo:session): Cannot create session: Already running in a session 7月 14 16:48:37 X1 audit[21024]: USER_START pid=21024 uid=0 auid=1000 ses=2 msg='op=PAM:session_open grantors=pam_keyini $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.11.9-200.fc25.x86_64 root=UUID=270d1753-e6c2-4a51-8d1f-46daa025e8d0 ro rootflags=subvol=root rhgb quiet LANG=zh_CN.UTF-8 crashkernel=256M $ grep -v ^# /etc/kdump.conf path /var/crash core_collector makedumpfile -l --message-level 1 -d 31 $ rpm -q kernel kexec-tools kernel-4.11.9-200.fc25.x86_64 kexec-tools-2.0.13-7.fc25.3.x86_64 Version-Release number of selected component (if applicable): $ rpm -q kernel kexec-tools kernel-4.11.9-200.fc25.x86_64 kexec-tools-2.0.13-7.fc25.3.x86_64 How reproducible: 100% Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
4.8.6-300.fc25.x86_64 works well 4.11.9-200.fc25 does not work, fc26 kernels also do not work. But boot with 4.8.6-300.fc25 and then kexec -s -l other any Fedora kernels works just fine. Kexec -s -l will verify the kernel signature but probably the running kernel does not has the keys to verify it or some code bug, I'm not sure. Maybe some Fedora kernel changes or upstream changes caused this.. Laura, are you aware some Fedora kernel changes which could cause the failure?
Also cc Josh Boyer and David Howells for thoughts.
Can we get the output of: cat /proc/keys keyctl show %:.secondary_trusted_keys
Created attachment 1299781 [details] /proc/keys
Attached /proc/keys, trusted keys see below: 987969622 ---lswrv 0 0 keyring: .secondary_trusted_keys 225442601 ---lswrv 0 0 \_ keyring: .builtin_trusted_keys 292691363 ---lswrv 0 0 \_ asymmetric: Fedora kernel signing key: f336f8aa0ee9e2fc88e58929dfb0c242d031faf0
I think the problem is that it's no longer loading the keys from UEFI. Can you grep the bootup messsages in dmesg for "MODSIGN"?
Also grepping it for "Could" would be useful, eg. "Couldn't get UEFI db list".
Hmm, found nothing about "MODSIGN" and "Could" But there is below in dmesg: [ 0.000000] Secure boot could not be determined
It looks same as Bug 1451071 which was fixed in F26, this can be closed as duplicate to the f25 bug https://bugzilla.redhat.com/show_bug.cgi?id=1465517
grub2-2.02-0.40.fc26 works for me
*** This bug has been marked as a duplicate of bug 1465517 ***
But downloaded koji latest rawhide kernel still fails to be loaded as kexec kernel, the downloaded is 4.13.0-0.rc1.git0.1.fc27.x86_64 [root@localhost ~]# dmesg|grep Could [ 1.109264] Couldn't get size: 0x800000000000000e [ 1.110370] MODSIGN: Couldn't get UEFI dbx list [root@localhost ~]# keyctl show %:.secondary_trusted_keys Keyring 600488954 ---lswrv 0 0 keyring: .secondary_trusted_keys 1042652056 ---lswrv 0 0 \_ keyring: .builtin_trusted_keys 290273421 ---lswrv 0 0 | \_ asymmetric: Fedora kernel signing key: db4bfc26017f8c3c256c633d59be6a35e4b2bbbf 557247681 ---lswrv 0 0 \_ asymmetric: Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42 412294144 ---lswrv 0 0 \_ asymmetric: dyoung kernel test key: 9d5c9a70fe6578e1ba171ba2ab9f3449d6688559 448048368 ---lswrv 0 0 \_ asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4 51576861 ---lswrv 0 0 \_ asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53 [root@localhost ~]# cat /proc/keys 0046e7e0 I--Q--- 4 perm 3f030000 0 0 keyring _ses: 1 006780c4 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 014744d5 I--Q--- 3 perm 3f030000 0 0 keyring _ses: 1 01b58fd5 I--Q--- 6 perm 3f030000 0 0 keyring _ses: 1 0313001d I------ 2 perm 1f010000 0 0 asymmetri Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53: X509.rsa 7c55af53 [] 032d6034 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 0926d921 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 092b3bc5 I--Q--- 3 perm 3f030000 0 0 keyring _ses: 1 094a1d5e I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 0a021d62 I--Q--- 2 perm 3f030000 0 0 keyring _ses: 1 0b3bed02 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 0e8e5d96 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 0efe1fc3 I--Q--- 5 perm 3f030000 0 0 keyring _ses: 1 0f3be247 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 10645b62 I--Q--- 3 perm 3f030000 0 0 keyring _ses: 1 114d388d I------ 1 perm 1f030000 0 0 asymmetri Fedora kernel signing key: db4bfc26017f8c3c256c633d59be6a35e4b2bbbf: X509.rsa e4b2bbbf [] 124f2523 I--Q--- 2 perm 3f030000 0 0 keyring _ses: 1 139114bd I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 13e55d10 I--Q--- 3 perm 3f030000 0 0 keyring _ses: 1 15d5eee9 I--Q--- 4 perm 3f030000 0 0 keyring _ses: 1 17c93713 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 18931c00 I------ 2 perm 1f010000 0 0 asymmetri dyoung kernel test key: 9d5c9a70fe6578e1ba171ba2ab9f3449d6688559: X509.rsa d6688559 [] 1984845d I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 1ab4acf0 I------ 2 perm 1f010000 0 0 asymmetri Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4: X509.rsa 988a1bd4 [] 1b457837 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 1b6ba4b6 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 1c7d6f89 I------ 1 perm 1f0b0000 0 0 keyring .blacklist: empty 1cd13824 I--Q--- 12 perm 3f030000 0 0 keyring _ses: 1 1d7b08fa I--Q--- 3 perm 3f030000 0 0 keyring _ses: 1 20c1b00f I--Q--- 4 perm 3f030000 0 0 keyring _ses: 1 2136ecc1 I------ 2 perm 1f010000 0 0 asymmetri Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42: X509.rsa cd963b42 [] 22d8d974 I--Q--- 4 perm 1f3f0000 0 65534 keyring _uid.0: empty 238ce730 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 23cabbfa I------ 1 perm 1f0f0000 0 0 keyring .secondary_trusted_keys: 5 23d584fe I--Q--- 2 perm 3f030000 0 0 keyring _ses: 1 24154b68 I--Q--- 2 perm 3f030000 0 0 keyring _ses: 1 26308969 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 274e11eb I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 27d09c39 I--Q--- 2 perm 3f030000 0 0 keyring _ses: 1 27d8d607 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 289a3f18 I--Q--- 2 perm 3f030000 0 0 keyring _ses: 1 2ae99090 I--Q--- 1 perm 1f3f0000 0 65534 keyring _uid_ses.0: 1 2b435267 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 2e06a4c5 I--Q--- 1 perm 3f030000 0 0 keyring _ses: 1 311aff9b I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 32c874a7 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 32deb133 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 357a1d25 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 3581b9f5 I--Q--- 2 perm 3f030000 0 0 keyring _ses: 1 361d287b I--Q--- 2 perm 3f030000 0 0 keyring _ses: 1 3834e9e4 I--Q--- 5 perm 3f030000 0 0 keyring _ses: 1 3a784003 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 3aca6e03 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 3c33b0b7 I--Q--- 4 perm 3f030000 0 0 keyring _ses: 1 3c5f332c I--Q--- 2 perm 3f030000 0 0 keyring _ses: 1 3cecabb1 I--Q--- 2 perm 3f030000 0 0 keyring _ses: 1 3d064aaf I--Q--- 2 perm 3f030000 0 0 keyring _ses: 1 3e259b98 I------ 2 perm 1f0b0000 0 0 keyring .builtin_trusted_keys: 1 3e91fec9 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 3eea699a I--Q--- 2 perm 3f030000 0 0 keyring _ses: 1
I get these errors with kernel 4.12.8-200.fc25.x86_64: $ journalctl -b | grep "Couldn't get" Aug 18 14:08:03 Mobile-PC kernel: Couldn't get size: 0x800000000000000e Aug 18 14:08:03 Mobile-PC kernel: MODSIGN: Couldn't get UEFI MokListRT Gene
I'm seeing the issue on 4.12.5-200.
(In reply to Dave Young from comment #12) > But downloaded koji latest rawhide kernel still fails to be loaded as kexec > kernel, the downloaded is 4.13.0-0.rc1.git0.1.fc27.x86_64 > > [root@localhost ~]# dmesg|grep Could > [ 1.109264] Couldn't get size: 0x800000000000000e > [ 1.110370] MODSIGN: Couldn't get UEFI dbx list > > [root@localhost ~]# keyctl show %:.secondary_trusted_keys > Keyring > 600488954 ---lswrv 0 0 keyring: .secondary_trusted_keys > 1042652056 ---lswrv 0 0 \_ keyring: .builtin_trusted_keys > 290273421 ---lswrv 0 0 | \_ asymmetric: Fedora kernel signing > key: db4bfc26017f8c3c256c633d59be6a35e4b2bbbf > 557247681 ---lswrv 0 0 \_ asymmetric: Fedora Secure Boot CA: > fde32599c2d61db1bf5807335d7b20e4cd963b42 > 412294144 ---lswrv 0 0 \_ asymmetric: dyoung kernel test key: > 9d5c9a70fe6578e1ba171ba2ab9f3449d6688559 > 448048368 ---lswrv 0 0 \_ asymmetric: Microsoft Corporation UEFI > CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4 > 51576861 ---lswrv 0 0 \_ asymmetric: Microsoft Windows > Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53 > The difference with a succeeded kexec load is above keyring topology, a successful load has below instead, all the keys are children of .builtin_trusted_keys: [root@localhost ~]# keyctl show %:.secondary_trusted_keys Keyring 226685935 ---lswrv 0 0 keyring: .secondary_trusted_keys 737650623 ---lswrv 0 0 \_ keyring: .builtin_trusted_keys 188537896 ---lswrv 0 0 \_ asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53 680286201 ---lswrv 0 0 \_ asymmetric: Fedora kernel signing key: a97d6306ae6a6507bdc5a7857746bd9b5938a8b2 730880893 ---lswrv 0 0 \_ asymmetric: Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42 999568617 ---lswrv 0 0 \_ asymmetric: dyoung kernel test key: 9d5c9a70fe6578e1ba171ba2ab9f3449d6688559 624392117 ---lswrv 0 0 \_ asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4 So I guess there could be something wrong in keyring handling. David, thoughts?
I'm seeing this on Fedora 25, kernel 4.12.8-200.fc25 <snip> Loaded X.509 cert 'Fedora kernel signing key: 398a753857dc0c78270c5ab6a788888dbcf81b3c' Couldn't get size: 0x800000000000000e MODSIGN: Couldn't get UEFI db list Loaded UEFI:MokListRT cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42' linked to secondary sys keyring Couldn't get size: 0x800000000000000e MODSIGN: Couldn't get UEFI dbx list <snip
Seen in 4.12.8-300.fc26.x86_64 also kernel: AES CTR mode by8 optimization enabled kernel: registered taskstats version 1 kernel: Loading compiled-in X.509 certificates kernel: alg: No test for pkcs1pad(rsa,sha256) (pkcs1pad(rsa-generic,sha256)) kernel: Loaded X.509 cert 'Fedora kernel signing key: 1ac27581618ce74486fdf249f2e058b2523b2a90' kernel: Couldn't get size: 0x800000000000000e kernel: MODSIGN: Couldn't get UEFI db list kernel: Loaded UEFI:MokListRT cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42' linked to secondary sys keyring kernel: Couldn't get size: 0x800000000000000e kernel: MODSIGN: Couldn't get UEFI dbx list kernel: zswap: loaded using pool lzo/zbud kernel: Key type big_key registered kernel: Key type encrypted registered kernel: Magic number: 13:648:368 kernel: msr msr7: hash matches kernel: rtc_cmos 00:07: setting system clock to 2017-08-29 06:23:23 UTC (1503987803) kernel: PM: Hibernation image not present or could not be loaded. keyring : sudo keyctl show %:.secondary_trusted_keys Keyring 404045787 ---lswrv 0 0 keyring: .secondary_trusted_keys 487114892 ---lswrv 0 0 \_ keyring: .builtin_trusted_keys 252404789 ---lswrv 0 0 | \_ asymmetric: Fedora kernel signing key: 1ac27581618ce74486fdf249f2e058b2523b2a90 270588823 ---lswrv 0 0 \_ asymmetric: Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42
Any movement on this front? Can we get a status update?
Not sure if it relates to below patch, but I do not know how to test it especially about the different keyring issues. KEYS-Allow-unrestricted-boot-time-addition-of-keys-t.patch Still need David Howells's help
Add back the lost needinfo..
I recently installed f26 on my desktop and then did a dnf update right afterwards. I also installed nvidia drivers following the instructions here: https://rpmfusion.org/Howto/NVIDIA Every time, or just about every time, I boot I get the message: Couldn't get size 0x........... MODSIGN: Couldn't get UEFI db list Couldn't get size 0x........... I've got the journalctl entries from when the computer was booted. I would attach the file with the journalctl entries if there was a way to do it, but I don't see any. The file is a bit large so I don't want to paste the contents into this comment. Please contact me if you need the journalctl contents.
I have the same kind of problem with my Chromebook HP 14 (Falco) with MattDevo firmware. Here is the message I have on boot with Fedora 26 and kernel 4.12 and up. sept. 12 00:56:17 hp kernel: Couldn't get size: 0x800000000000000e sept. 12 00:56:17 hp kernel: MODSIGN: Couldn't get UEFI db list sept. 12 00:56:17 hp kernel: Couldn't get size: 0x800000000000000e
I get the same error messages as Comment 22 above. Dell 6520 Latitude laptop here with hybrid graphics and Optimus technology (Intel integrated + Nvidia discrete), UEFI enabled but no secure boot available. Thanks
I have a same error right after my major package update(fc25 to fc26) since Aug 2017 Aug 20 00:08:49 vafa-lap kernel: zswap: loaded using pool lzo/zbud Aug 20 00:08:49 vafa-lap kernel: Key type big_key registered Aug 20 00:08:49 vafa-lap kernel: Key type encrypted registered Aug 20 00:08:49 vafa-lap kernel: Magic number: 13:108:113 Aug 20 00:08:49 vafa-lap kernel: registered taskstats version 1 Aug 20 00:08:49 vafa-lap kernel: Loading compiled-in X.509 certificates Aug 20 00:08:49 vafa-lap kernel: alg: No test for pkcs1pad(rsa,sha256) (pkcs1pad(rsa-generic,sha256)) Aug 20 00:08:49 vafa-lap kernel: Loaded X.509 cert 'Fedora kernel signing key: c59eb7bc258ea685d356097bc77d1b42d3512906' Aug 20 00:08:49 vafa-lap kernel: Couldn't get size: 0x800000000000000e Aug 20 00:08:49 vafa-lap kernel: MODSIGN: Couldn't get UEFI db list Aug 20 00:08:49 vafa-lap kernel: Loaded UEFI:MokListRT cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42' linked to se Aug 20 00:08:49 vafa-lap kernel: Couldn't get size: 0x800000000000000e Aug 20 00:08:49 vafa-lap kernel: MODSIGN: Couldn't get UEFI dbx list Aug 20 00:08:49 vafa-lap kernel: zswap: loaded using pool lzo/zbud Aug 20 00:08:49 vafa-lap kernel: Key type big_key registered Aug 20 00:08:49 vafa-lap kernel: Key type encrypted registered
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I'm still seeing this on F27. Can somebody change the version please?
Posted a patch which should fix this, I verified self signed kernel, but I can not verify Fedora official keys: http://lists.infradead.org/pipermail/kexec/2017-November/019632.html
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. As kernel maintainers, we try to keep up with bugzilla but due the rate at which the upstream kernel project moves, bugs may be fixed without any indication to us. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs. Fedora 27 has now been rebased to 4.15.3-300.f27. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
This bug is fixed by kernel-4.15.3-300.f27 for me. Thanks! Gene
Thanks for confirming!
I do not have F27, but this is still reproducible in rawhide, I'm just reopening it for rawhide.
Created attachment 1450772 [details] A patch posted for Fedora kernel
kernel-4.16.16-200.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c449dc1c9c
kernel-4.16.16-300.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-bb7aab12cb
kernel-4.16.16-200.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c449dc1c9c
kernel-4.16.16-300.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-bb7aab12cb
Both f28 and rawhide build works for me, thanks!
kernel-4.16.16-300.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
kernel-4.16.16-200.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
For reference purpose, below upstream fixes fixed this issue: commit ea93102f32244e3f45c8b26260be77ed0cc1d16c Author: Yannik Sembritzki <yannik> Date: Thu Aug 16 14:05:23 2018 +0100 Fix kexec forbidding kernels signed with keys in the secondary keyring to boot commit 817aef260037f33ee0f44c17fe341323d3aebd6d Author: Yannik Sembritzki <yannik> Date: Thu Aug 16 14:05:10 2018 +0100 Replace magic for trusting the secondary keyring with #define
The bug is reproduced on fedora 33: version: kernel-5.9.8-200.fc33.x86_64 kexec-tools-2.0.20-17.fc33.x86_64 service status: ● kdump.service - Crash recovery kernel arming Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2020-11-17 16:27:06 CST; 6min ago Process: 5259 ExecStart=/usr/bin/kdumpctl start (code=exited, status=1/FAILURE) Main PID: 5259 (code=exited, status=1/FAILURE) CPU: 28.073s Nov 17 16:27:05 localhost.localdomain dracut[5689]: *** Creating image file '/boot/initramfs-5.9.8-200.fc33.x86_64kdump.img' *** Nov 17 16:27:06 localhost.localdomain dracut[5689]: *** Creating initramfs image file '/boot/initramfs-5.9.8-200.fc33.x86_64kdump.img' done *** Nov 17 16:27:06 localhost.localdomain kdumpctl[5264]: Secure Boot is enabled. Using kexec file based syscall. Nov 17 16:27:06 localhost.localdomain kdumpctl[9981]: kexec_file_load failed: Operation not permitted Nov 17 16:27:06 localhost.localdomain kdumpctl[5264]: kexec: failed to load kdump kernel Nov 17 16:27:06 localhost.localdomain kdumpctl[5264]: Starting kdump: [FAILED] Nov 17 16:27:06 localhost.localdomain systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE Nov 17 16:27:06 localhost.localdomain systemd[1]: kdump.service: Failed with result 'exit-code'. Nov 17 16:27:06 localhost.localdomain systemd[1]: Failed to start Crash recovery kernel arming. Nov 17 16:27:06 localhost.localdomain systemd[1]: kdump.service: Consumed 28.073s CPU time. journal: -- Reboot -- Nov 17 16:26:56 localhost.localdomain systemd[1]: Starting Crash recovery kernel arming... Nov 17 16:26:56 localhost.localdomain kdumpctl[5264]: No kdump initial ramdisk found. Nov 17 16:26:56 localhost.localdomain kdumpctl[5264]: Rebuilding /boot/initramfs-5.9.8-200.fc33.x86_64kdump.img Nov 17 16:26:56 localhost.localdomain kdumpctl[5348]: Device /dev/dm-0 is encrypted. Nov 17 16:26:56 localhost.localdomain kdumpctl[5348]: Warning: Encrypted device is in dump path. User will prompted for password during second kernel boot. Nov 17 16:26:57 localhost.localdomain dracut[5689]: Executing: /usr/bin/dracut --quiet --hostonly --hostonly-cmdline --hostonly-i18n --hostonly-mode strict -o "plymouth dash resume ifcfg earlykdump" --mount "/dev/mapper/luks-707111a5-f607-4b47-90c9-070828ac2e20 /sysroot ext4 rw,relatime,seclabel,nofail,x-systemd.before=initrd-fs.target" --no-hostonly-default-device -f /boot/initramfs-5.9.8-200.fc33.x86_64kdump.img 5.9.8-200.fc33.x86_64 Nov 17 16:26:57 localhost.localdomain dracut[5689]: dracut module 'ifcfg' will not be installed, because it's in the list to be omitted! Nov 17 16:26:57 localhost.localdomain dracut[5689]: dracut module 'plymouth' will not be installed, because it's in the list to be omitted! Nov 17 16:26:57 localhost.localdomain dracut[5689]: dracut module 'dmraid' will not be installed, because command 'dmraid' could not be found! Nov 17 16:26:57 localhost.localdomain dracut[5689]: dracut module 'stratis' will not be installed, because command 'stratisd-init' could not be found! Nov 17 16:26:57 localhost.localdomain dracut[5689]: dracut module 'resume' will not be installed, because it's in the list to be omitted! Nov 17 16:26:57 localhost.localdomain dracut[5689]: dracut module 'biosdevname' will not be installed, because command 'biosdevname' could not be found! Nov 17 16:26:57 localhost.localdomain dracut[5689]: dracut module 'earlykdump' will not be installed, because it's in the list to be omitted! Nov 17 16:26:57 localhost.localdomain dracut[5689]: memstrack is available Nov 17 16:26:57 localhost.localdomain dracut[5689]: dracut module 'dmraid' will not be installed, because command 'dmraid' could not be found! Nov 17 16:26:57 localhost.localdomain dracut[5689]: dracut module 'stratis' will not be installed, because command 'stratisd-init' could not be found! Nov 17 16:26:57 localhost.localdomain dracut[5689]: *** Including module: bash *** Nov 17 16:26:57 localhost.localdomain dracut[5689]: *** Including module: systemd *** Nov 17 16:26:58 localhost.localdomain dracut[5689]: *** Including module: systemd-initrd *** Nov 17 16:26:58 localhost.localdomain dracut[5689]: *** Including module: nss-softokn *** Nov 17 16:26:58 localhost.localdomain dracut[5689]: *** Including module: rngd *** Nov 17 16:26:58 localhost.localdomain dracut[5689]: *** Including module: i18n *** Nov 17 16:26:58 localhost.localdomain dracut[5689]: *** Including module: drm *** Nov 17 16:26:58 localhost.localdomain dracut[5689]: *** Including module: crypt *** Nov 17 16:26:58 localhost.localdomain dracut[5689]: *** Including module: dm *** Nov 17 16:26:58 localhost.localdomain dracut[5689]: Skipping udev rule: 64-device-mapper.rules Nov 17 16:26:58 localhost.localdomain dracut[5689]: Skipping udev rule: 60-persistent-storage-dm.rules Nov 17 16:26:58 localhost.localdomain dracut[5689]: Skipping udev rule: 55-dm.rules Nov 17 16:26:58 localhost.localdomain dracut[5689]: *** Including module: kernel-modules *** Nov 17 16:26:59 localhost.localdomain dracut[5689]: *** Including module: kernel-modules-extra *** Nov 17 16:26:59 localhost.localdomain dracut[5689]: kernel-modules-extra: configuration source "/run/depmod.d/" does not exist Nov 17 16:26:59 localhost.localdomain dracut[5689]: kernel-modules-extra: configuration source "/etc/depmod.d/" is ignored (directory or doesn't exist) Nov 17 16:26:59 localhost.localdomain dracut[5689]: kernel-modules-extra: configuration source "/lib/depmod.d/" does not exist Nov 17 16:26:59 localhost.localdomain dracut[5689]: *** Including module: lvm *** Nov 17 16:26:59 localhost.localdomain dracut[5689]: Skipping udev rule: 64-device-mapper.rules Nov 17 16:26:59 localhost.localdomain dracut[5689]: Skipping udev rule: 56-lvm.rules Nov 17 16:26:59 localhost.localdomain dracut[5689]: Skipping udev rule: 60-persistent-storage-lvm.rules Nov 17 16:26:59 localhost.localdomain dracut[5689]: *** Including module: fstab-sys *** Nov 17 16:26:59 localhost.localdomain dracut[5689]: *** Including module: rootfs-block *** Nov 17 16:26:59 localhost.localdomain dracut[5689]: *** Including module: terminfo *** Nov 17 16:26:59 localhost.localdomain dracut[5689]: *** Including module: udev-rules *** Nov 17 16:26:59 localhost.localdomain dracut[5689]: Skipping udev rule: 40-redhat.rules Nov 17 16:26:59 localhost.localdomain dracut[5689]: Skipping udev rule: 50-firmware.rules Nov 17 16:26:59 localhost.localdomain dracut[5689]: Skipping udev rule: 50-udev.rules Nov 17 16:26:59 localhost.localdomain dracut[5689]: Skipping udev rule: 91-permissions.rules Nov 17 16:26:59 localhost.localdomain dracut[5689]: Skipping udev rule: 80-drivers-modprobe.rules Nov 17 16:26:59 localhost.localdomain dracut[5689]: Skipping udev rule: 70-persistent-net.rules Nov 17 16:26:59 localhost.localdomain dracut[5689]: *** Including module: dracut-systemd *** Nov 17 16:26:59 localhost.localdomain dracut[5689]: *** Including module: usrmount *** Nov 17 16:26:59 localhost.localdomain dracut[5689]: *** Including module: base *** Nov 17 16:26:59 localhost.localdomain dracut[5689]: *** Including module: fs-lib *** Nov 17 16:26:59 localhost.localdomain dracut[5689]: *** Including module: kdumpbase *** Nov 17 16:27:00 localhost.localdomain dracut[5689]: *** Including module: memstrack *** Nov 17 16:27:00 localhost.localdomain dracut[5689]: *** Including module: shutdown *** Nov 17 16:27:00 localhost.localdomain dracut[5689]: *** Including module: squash *** Nov 17 16:27:00 localhost.localdomain dracut[5689]: *** Including modules done *** Nov 17 16:27:00 localhost.localdomain dracut[5689]: *** Installing kernel module dependencies *** Nov 17 16:27:00 localhost.localdomain dracut[5689]: *** Installing kernel module dependencies done *** Nov 17 16:27:00 localhost.localdomain dracut[5689]: *** Resolving executable dependencies *** Nov 17 16:27:01 localhost.localdomain dracut[5689]: *** Resolving executable dependencies done *** Nov 17 16:27:01 localhost.localdomain dracut[5689]: *** Hardlinking files *** Nov 17 16:27:02 localhost.localdomain dracut[5689]: *** Hardlinking files done *** Nov 17 16:27:02 localhost.localdomain dracut[5689]: *** Generating early-microcode cpio image *** Nov 17 16:27:02 localhost.localdomain dracut[5689]: *** Constructing GenuineIntel.bin *** Nov 17 16:27:02 localhost.localdomain dracut[5689]: *** Store current command line parameters *** Nov 17 16:27:02 localhost.localdomain dracut[5689]: Stored kernel commandline: Nov 17 16:27:02 localhost.localdomain dracut[5689]: rd.luks.uuid=luks-707111a5-f607-4b47-90c9-070828ac2e20 Nov 17 16:27:02 localhost.localdomain dracut[5689]: rd.lvm.lv=fedora/root Nov 17 16:27:02 localhost.localdomain dracut[5689]: *** Install squash loader *** Nov 17 16:27:02 localhost.localdomain dracut[5689]: *** Stripping files *** Nov 17 16:27:02 localhost.localdomain dracut[5689]: *** Stripping files done *** Nov 17 16:27:02 localhost.localdomain dracut[5689]: *** Squashing the files inside the initramfs *** Nov 17 16:27:05 localhost.localdomain dracut[5689]: *** Squashing the files inside the initramfs done *** Nov 17 16:27:05 localhost.localdomain dracut[5689]: *** Creating image file '/boot/initramfs-5.9.8-200.fc33.x86_64kdump.img' *** Nov 17 16:27:06 localhost.localdomain dracut[5689]: *** Creating initramfs image file '/boot/initramfs-5.9.8-200.fc33.x86_64kdump.img' done *** Nov 17 16:27:06 localhost.localdomain kdumpctl[5264]: Secure Boot is enabled. Using kexec file based syscall. Nov 17 16:27:06 localhost.localdomain kdumpctl[9981]: kexec_file_load failed: Operation not permitted Nov 17 16:27:06 localhost.localdomain kdumpctl[5264]: kexec: failed to load kdump kernel Nov 17 16:27:06 localhost.localdomain kdumpctl[5264]: Starting kdump: [FAILED] Nov 17 16:27:06 localhost.localdomain systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE Nov 17 16:27:06 localhost.localdomain systemd[1]: kdump.service: Failed with result 'exit-code'. Nov 17 16:27:06 localhost.localdomain systemd[1]: Failed to start Crash recovery kernel arming. Nov 17 16:27:06 localhost.localdomain systemd[1]: kdump.service: Consumed 28.073s CPU time.
Same for kernel-5.13.9-100.fc33.x86_64 and kexec-tools-2.0.21-4.fc33.x86_64
This is still an issue with F35: kernel-5.16.9-200.fc35.x86_64 kexec-tools-2.0.22-7.fc35.x86_64 $ sudo keyctl show %:.secondary_trusted_keys Keyring 217842805 ---lswrv 0 0 keyring: .secondary_trusted_keys 145479186 ---lswrv 0 0 \_ keyring: .builtin_trusted_keys 8483157 ---lswrv 0 0 \_ asymmetric: Fedora kernel signing key: 71e9cee098ffc48270bb96b67cb3c520e6fa2cc3 $ systemctl status kdump.service × kdump.service - Crash recovery kernel arming Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2022-02-23 00:03:01 CET; 25min ago Main PID: 1035 (code=exited, status=1/FAILURE) CPU: 571ms Feb 23 00:03:00 lenovo systemd[1]: Starting Crash recovery kernel arming... Feb 23 00:03:01 lenovo kdumpctl[1044]: kdump: Secure Boot is enabled. Using kexec file based syscall. Feb 23 00:03:01 lenovo kdumpctl[1044]: kdump: kexec: failed to load kdump kernel Feb 23 00:03:01 lenovo kdumpctl[1044]: kdump: Starting kdump: [FAILED] Feb 23 00:03:01 lenovo systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE Feb 23 00:03:01 lenovo systemd[1]: kdump.service: Failed with result 'exit-code'. Feb 23 00:03:01 lenovo systemd[1]: Failed to start Crash recovery kernel arming. Can this bug please be reopened?