Bug 1188142 - Kernel 5.13.1 does not boot due to bad shim signature
Kernel 5.13.1 does not boot due to bad shim signature
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
x86-64 Other
: P3 - Medium : Normal with 1 vote (vote)
: ---
Assigned To: Ludwig Nussel
E-mail List
:
Depends on:
Blocks: 1184804
  Show dependency treegraph
 
Reported: 2021-07-08 17:57 UTC by Frank Krüger
Modified: 2021-08-11 18:18 UTC (History)
8 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Krüger 2021-07-08 17:57:53 UTC
Given TW20200706 with shim-15.4-3.1.x86_64, secure boot and Kernel:stable repo enabled, kernel-default-5.13.1-1.1.gbebf622.x86_64 and kernel-default-5.13.0-5.1.g9140415.x86_64 do not boot with the error message

Loading Linux kernel-default-5.13.1-1.1.gbebf622.x86_64 ...
error: ../../grub-core/kern/efi/sb.c:151:bad shim signature.
Loading initial ramdisk ...
error: ../../grub-core/loader/i386/efi/linux.c.98:you need to load the kernel first.

Version 5.13.0-3.1.g531fe4a.x86_64 boots fine.
Comment 1 Yan Huang 2021-07-09 16:56:01 UTC
I have encountered exactly the same issue with the Kernel:stable kernel 5.13.1-1.1.gbebf622 from https://software.opensuse.org/download/package?package=kernel-default&project=Kernel%3Astable and Secure Boot enabled (on Tumbleweed 20210707).

I think the issue actually started with the Kernel:stable kernel 5.13.0-5.1.g9140415.
Comment 2 Yan Huang 2021-07-09 17:02:10 UTC
(The workaround is to temporarily disable Secure Boot.)
Comment 3 Frank Krüger 2021-07-09 20:13:32 UTC
(In reply to Yan Huang from comment #2)
> (The workaround is to temporarily disable Secure Boot.)

WOW!!!!!
Comment 4 Andres Nogueiras 2021-07-10 10:24:29 UTC
(In reply to Frank Krüger from comment #3)
> (In reply to Yan Huang from comment #2)
> > (The workaround is to temporarily disable Secure Boot.)
> 
> WOW!!!!!

What if we are not allowed to change this settings in the BIOS? (Company policy)

And I can confirm that this also started on my machine with kernel-default-5.13.0-5.1
Comment 5 Yan Huang 2021-07-10 20:42:12 UTC
(In reply to Frank Krüger from comment #3)
> (In reply to Yan Huang from comment #2)
> > (The workaround is to temporarily disable Secure Boot.)
> 
> WOW!!!!!

Hi Frank,

I am very sorry that I suggested disabling Secure Boot.
I am aware that it might involve security risk - that is why I mentioned "workaround" and "temporarily".

I only suggested disabling Secure Boot
- after successfully testing it on my own laptop that had exactly the same issue
- in case you wish to boot the newest (and still affected) Kernel:stable kernel 5.13.1-1.1.gbebf622 as soon as possible

Disclaimer:
I am not a kernel developer, I am not from SUSE Engineering & Innovation.
I am rather just a junior member of SUSE Customer Support.
Comment 6 Frank Krüger 2021-07-10 21:34:22 UTC
(In reply to Yan Huang from comment #5)
> (In reply to Frank Krüger from comment #3)
> > (In reply to Yan Huang from comment #2)
> > > (The workaround is to temporarily disable Secure Boot.)
> > 
> > WOW!!!!!
> 
> Hi Frank,
> 
> I am very sorry that I suggested disabling Secure Boot.
> I am aware that it might involve security risk - that is why I mentioned
> "workaround" and "temporarily".
> 
> I only suggested disabling Secure Boot
> - after successfully testing it on my own laptop that had exactly the same
> issue
> - in case you wish to boot the newest (and still affected) Kernel:stable
> kernel 5.13.1-1.1.gbebf622 as soon as possible
> 
> Disclaimer:
> I am not a kernel developer, I am not from SUSE Engineering & Innovation.
> I am rather just a junior member of SUSE Customer Support.

Not to worry, Yan. I was just astonished by your suggestion to disable secure boot. Thanks for the clarifiction.
Comment 7 Jiri Slaby 2021-07-12 09:34:57 UTC
Is this another usrmerge fallout? Does current (when it builds) work for you? I've reverted the change this morning.
Comment 8 Yan Huang 2021-07-12 13:46:09 UTC
(In reply to Jiri Slaby from comment #7)
> Is this another usrmerge fallout? Does current (when it builds) work for
> you? I've reverted the change this morning.

Thanks, Jiri.

But the newest Kernel:stable kernel 5.13.1-3.1.gbebf622 (if this one already has the change reverted) still has the issue - at least on my laptop.
Comment 9 Yan Huang 2021-07-12 13:51:25 UTC
I re-checked the system logs on my laptop and can confirm that
- 5.13.0-4.gaa40472 was the last Kernel:stable kernel that could successfully boot with Secure Boot enabled
- the issue indeed started with 5.13.0-5.1.g9140415
Comment 10 Jiri Slaby 2021-07-12 15:20:48 UTC
(In reply to Yan Huang from comment #9)
> I re-checked the system logs on my laptop and can confirm that
> - 5.13.0-4.gaa40472 was the last Kernel:stable kernel that could
> successfully boot with Secure Boot enabled
> - the issue indeed started with 5.13.0-5.1.g9140415

This range contains exactly the commit I reverted. But 5.13.1-3.1.gbebf622 contains the revert already and still causes the trouble... I am lost.
Comment 11 Frank Krüger 2021-07-12 17:34:46 UTC
(In reply to Jiri Slaby from comment #10)
> (In reply to Yan Huang from comment #9)
> > I re-checked the system logs on my laptop and can confirm that
> > - 5.13.0-4.gaa40472 was the last Kernel:stable kernel that could
> > successfully boot with Secure Boot enabled
> > - the issue indeed started with 5.13.0-5.1.g9140415
> 
> This range contains exactly the commit I reverted. But 5.13.1-3.1.gbebf622
> contains the revert already and still causes the trouble... I am lost.

Unfortunately, kernel-default-5.13.1-3.1.gbebf622.x86_64 does not boot either, as alreday confirmed by comment #8.
Comment 12 Jiri Slaby 2021-07-13 06:23:43 UTC
(In reply to Frank Krüger from comment #11)
> (In reply to Jiri Slaby from comment #10)
> > (In reply to Yan Huang from comment #9)
> > > I re-checked the system logs on my laptop and can confirm that
> > > - 5.13.0-4.gaa40472 was the last Kernel:stable kernel that could
> > > successfully boot with Secure Boot enabled
> > > - the issue indeed started with 5.13.0-5.1.g9140415
> > 
> > This range contains exactly the commit I reverted. But 5.13.1-3.1.gbebf622
> > contains the revert already and still causes the trouble... I am lost.
> 
> Unfortunately, kernel-default-5.13.1-3.1.gbebf622.x86_64 does not boot
> either, as alreday confirmed by comment #8.

Sorry, my fault: gbebf622 does not contain the revert yet!

g72aabc28 or gb6ab3de do. Look for 'Revert "UsrMerge the kernel (boo#1184804)"' in the changelog. But it's currently building yet, so you have to wait until it is finished.
Comment 13 Jiri Slaby 2021-07-13 06:25:26 UTC
FWIW works for me:
> [    0.000000] Linux version 5.13.1-21.g72aabc2-default (geeko@buildhost) (gcc (SUSE Linux) 11.1.1 20210625 [revision 62bbb113ae68a7e724255e17143520735bcb9ec9], GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.36.1.20210326-4) #1 SMP Mon Jul 12 06:35:58 UTC 2021 (72aabc2)
> [    0.018709] Secure boot enabled
Comment 14 Yan Huang 2021-07-13 11:08:27 UTC
I can confirm that 5.13.1-4.1.g72aabc2 (now available in the Kernel:stable repo) is bootable on my laptop with Secure Boot enabled. Thanks.
Comment 15 Andres Nogueiras 2021-07-13 15:01:49 UTC
I also confirm that 5.13.1-4.1.g72aabc2 now boot without problems.

Thanks!
Comment 16 Frank Krüger 2021-07-13 17:14:23 UTC
(In reply to Jiri Slaby from comment #13)
> FWIW works for me:
> > [    0.000000] Linux version 5.13.1-21.g72aabc2-default (geeko@buildhost) (gcc (SUSE Linux) 11.1.1 20210625 [revision 62bbb113ae68a7e724255e17143520735bcb9ec9], GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.36.1.20210326-4) #1 SMP Mon Jul 12 06:35:58 UTC 2021 (72aabc2)
> > [    0.018709] Secure boot enabled

kernel-default-5.13.1-4.1.g72aabc2.x86_64 boots fine for me as well. Thx.
Comment 17 Ludwig Nussel 2021-07-26 08:53:56 UTC
FWIW I checked my test system. It has secure boot on, so this did work. I used the master branch though and had linux-5.13-rc6 last. So maybe some subtle difference between stable and master. Will try again with stable branch.
Comment 18 Jiri Slaby 2021-07-27 05:45:28 UTC
(In reply to Ludwig Nussel from comment #17)
> FWIW I checked my test system. It has secure boot on, so this did work. I
> used the master branch though and had linux-5.13-rc6 last. So maybe some
> subtle difference between stable and master. Will try again with stable
> branch.

For me, current master doesn't boot:
Loading Linux 5.14.0-rc3-1.gee7a475-default ...
error: ../../grub-core/kern/efi/sb.c:150:bad shim signature.
Loading initial ramdisk ...
error: ../../grub-core/loader/i386/efi/linux.c:98:you need to load the kernel
first.

Press any key to continue...

  Failed to boot both default and fallback entries.


(Current stable does.)
Comment 19 Ludwig Nussel 2021-07-28 13:21:05 UTC
missed a bit in pesign-obs-integration indeed. Fix on the way
Comment 20 Frank Krüger 2021-08-11 18:18:09 UTC
After the revert of the revert, kernel-default-5.13.9-2.1.g2e9639b.x86_64 boot just fine. Closing as fixed. Thank you!