Bug 1470995 - Can't start Kdump with SecureBoot enabled [NEEDINFO]
Summary: Can't start Kdump with SecureBoot enabled
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Dave Young
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-14 08:50 UTC by Chao Ye
Modified: 2018-11-15 05:27 UTC (History)
27 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-06-20 01:51:34 UTC
ruyang: needinfo? (dhowells)
labbott: needinfo? (cye)


Attachments (Terms of Use)
/proc/keys (4.12 KB, text/plain)
2017-07-17 10:54 UTC, Dave Young
no flags Details
A patch posted for Fedora kernel (2.33 KB, text/plain)
2018-06-13 03:22 UTC, Dave Young
no flags Details

Description Chao Ye 2017-07-14 08:50:30 UTC
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:

Comment 1 Dave Young 2017-07-17 02:26:18 UTC

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?

Comment 2 Dave Young 2017-07-17 02:31:21 UTC
Also cc Josh Boyer and David Howells for thoughts.

Comment 3 David Howells 2017-07-17 08:00:27 UTC
Can we get the output of:

    cat /proc/keys
    keyctl show %:.secondary_trusted_keys

Comment 4 Dave Young 2017-07-17 10:54 UTC
Created attachment 1299781 [details]
/proc/keys

Comment 5 Dave Young 2017-07-17 10:55:21 UTC
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

Comment 6 David Howells 2017-07-17 14:31:16 UTC
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"?

Comment 7 David Howells 2017-07-17 14:34:09 UTC
Also grepping it for "Could" would be useful, eg. "Couldn't get UEFI db list".

Comment 8 Dave Young 2017-07-18 01:27:18 UTC
Hmm, found nothing about "MODSIGN" and "Could"

But there is below in dmesg:
[    0.000000] Secure boot could not be determined

Comment 9 Dave Young 2017-07-18 07:01:50 UTC
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

Comment 10 Dave Young 2017-07-18 07:02:23 UTC
grub2-2.02-0.40.fc26 works for me

Comment 11 Dave Young 2017-07-18 07:03:01 UTC

*** This bug has been marked as a duplicate of bug 1465517 ***

Comment 12 Dave Young 2017-07-18 08:30:26 UTC
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

Comment 13 Gene Snider 2017-08-20 20:20:38 UTC
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

Comment 14 Andy 2017-08-23 07:15:44 UTC
I'm seeing the issue on 4.12.5-200.

Comment 15 Dave Young 2017-08-24 06:37:08 UTC
(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?

Comment 16 Chad 2017-08-25 17:15:44 UTC
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

Comment 17 NR 2017-08-30 07:10:44 UTC
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

Comment 18 Chad 2017-08-30 12:13:33 UTC
Any movement on this front?  Can we get a status update?

Comment 19 Dave Young 2017-08-31 01:39:42 UTC
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

Comment 20 Dave Young 2017-08-31 01:40:24 UTC
Add back the lost needinfo..

Comment 21 nickdu 2017-09-08 00:57:31 UTC
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.

Comment 22 jeremy9856 2017-09-17 22:02:15 UTC
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

Comment 23 horizonbrave 2017-10-17 04:43:18 UTC
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

Comment 24 Vafa 2017-10-19 18:22:09 UTC
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

Comment 25 Fedora End Of Life 2017-11-16 18:54:03 UTC
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.

Comment 26 Andy 2017-11-16 19:09:56 UTC
I'm still seeing this on F27.

Can somebody change the version please?

Comment 27 Dave Young 2017-11-18 04:49:27 UTC
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

Comment 28 Laura Abbott 2018-02-20 19:52:18 UTC
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.

Comment 29 Gene Snider 2018-02-20 20:39:35 UTC
This bug is fixed by kernel-4.15.3-300.f27 for me.

Thanks!
Gene

Comment 30 Laura Abbott 2018-02-20 21:05:47 UTC
Thanks for confirming!

Comment 31 Dave Young 2018-06-08 07:08:53 UTC
I do not have F27, but this is still reproducible in rawhide, I'm just reopening it for rawhide.

Comment 32 Dave Young 2018-06-13 03:22 UTC
Created attachment 1450772 [details]
A patch posted for Fedora kernel

Comment 33 Fedora Update System 2018-06-17 14:07:02 UTC
kernel-4.16.16-200.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c449dc1c9c

Comment 34 Fedora Update System 2018-06-17 14:07:53 UTC
kernel-4.16.16-300.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-bb7aab12cb

Comment 35 Fedora Update System 2018-06-17 19:38:19 UTC
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

Comment 36 Fedora Update System 2018-06-17 20:19:48 UTC
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

Comment 37 Dave Young 2018-06-19 02:48:43 UTC
Both f28 and rawhide build works for me, thanks!

Comment 38 Fedora Update System 2018-06-20 01:51:34 UTC
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.

Comment 39 Fedora Update System 2018-06-22 14:11:09 UTC
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.

Comment 40 Dave Young 2018-11-15 05:27:34 UTC
For reference purpose, below upstream fixes fixed this issue:

commit ea93102f32244e3f45c8b26260be77ed0cc1d16c
Author: Yannik Sembritzki <yannik@sembritzki.me>
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@sembritzki.me>
Date:   Thu Aug 16 14:05:10 2018 +0100

    Replace magic for trusting the secondary keyring with #define


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