Bugzilla – Full Text Bug Listing |
Summary: | Kernel 5.13.1 does not boot due to bad shim signature | ||
---|---|---|---|
Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Frank Krüger <fkrueger> |
Component: | Kernel | Assignee: | Ludwig Nussel <lnussel> |
Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
Severity: | Normal | ||
Priority: | P3 - Medium | CC: | anogueiras, fkrueger, glin, jslaby, lnussel, mchang, tiwai, yan.huang |
Version: | Current | ||
Target Milestone: | --- | ||
Hardware: | x86-64 | ||
OS: | Other | ||
Whiteboard: | |||
Found By: | --- | Services Priority: | |
Business Priority: | Blocker: | --- | |
Marketing QA Status: | --- | IT Deployment: | --- |
Bug Depends on: | |||
Bug Blocks: | 1184804 |
Description
Frank Krüger
2021-07-08 17:57:53 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. (The workaround is to temporarily disable Secure Boot.) (In reply to Yan Huang from comment #2) > (The workaround is to temporarily disable Secure Boot.) WOW!!!!! (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 (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. (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. Is this another usrmerge fallout? Does current (when it builds) work for you? I've reverted the change this morning. (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. 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 (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. (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. (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. 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
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. I also confirm that 5.13.1-4.1.g72aabc2 now boot without problems. Thanks! (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. 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. (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.) missed a bit in pesign-obs-integration indeed. Fix on the way After the revert of the revert, kernel-default-5.13.9-2.1.g2e9639b.x86_64 boot just fine. Closing as fixed. Thank you! |