Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1752961
| Summary: | After upgrading to Fedora 31 got a kernel panic loading 5.3.0 kernel | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Brandon Bennett <bbennett> | ||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 31 | CC: | abrahm.scully, airlied, alberto.patino.limon, awilliam, bskeggs, gaul, gmarr, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, jsnitsel, kernel-maint, kparal, labbott, leonid, linville, malucious81, masami256, mchehab, mjg59, mzink, pasik, pbrobinson, robatino, steved, thetaeridanus, tomek, vrutkovs | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | AcceptedFreezeException | ||||||||
| Fixed In Version: | kernel-5.3.2-300.fc31 | Doc Type: | If docs needed, set a value | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2019-10-04 20:05:53 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1269538, 1644939, 1644940 | ||||||||
| Attachments: |
|
||||||||
|
Description
Brandon Bennett
2019-09-17 16:32:56 UTC
part of the panic is cut off so it's hard to tell what's going on. I suspect this is an issue with not being able to open the root file system. Can you try booting without rhgb and quiet on the command line? Created attachment 1616025 [details]
Picture of panic w/ rhgb and quiet removed
Attached. It seems to be before mounting the root file system. This seems to be related: https://www.spinics.net/lists/linux-integrity/msg08544.html This affects an XPS 13 9370 with 5.3.0-1.fc31.x86_64 and 5.3.0-0.rc6.git0.1.fc31.x86_64. Booting 5.2.14-200.fc30.x86_64 doesn't exhibit the problem. When it panics, if I force power off and turn the laptop right back on the boot has been successful. Upgrading to 5.3.0-1.fc31 seems to have fixed the issue for me. *** Bug 1753521 has been marked as a duplicate of this bug. *** I just discovered this bug. Closing mine as duplicate - https://bugzilla.redhat.com/show_bug.cgi?id=1753521. System Information Manufacturer: LENOVO Product Name: 20L8S2N80D Version: ThinkPad T480s Wake-up Type: Power Switch SKU Number: LENOVO_MT_20L8_BU_Think_FM_ThinkPad T480s Family: ThinkPad T480s I've tried kernel-5.4.0-0.rc0.git2.1.fc32 kernel-5.3.0-1.fc31 kernel-5.3.0-0.rc6.git0.1.fc31 And all are the same -> kernel panic Exactly the same as https://www.spinics.net/lists/linux-integrity/msg08544.html 5.2.15-200.fc30.x86_64 - works perfect Same problem on T470s with 5.3.0-0.rc6.git0.1 and 5.3.0-1. Interestingly, I managed to boot into F31 for a few times after the upgrade. This started happening a few "dnf update"s later. Disabling Secure Boot allows my NUC8i7BEH to boot with 5.3.0-1.fc31.x86_64. I get the same problem after upgrading to fedora 31 on a Dell laptop with an Intel® Core™ i7-8650U CPU. I have noticed that it doesn't happen on every boot. Maybe 1 out of three. Happening on 5.3.0-1.fc31.x86_64 and also the previous RC kernel I have a workaround. The message speaks about "TPM address not". I've disabled TPM module in BIOS and system is booting normally. There must be some kind of regression in tpm module I assume. (In reply to Milan Zink from comment #12) > I have a workaround. The message speaks about "TPM address not". I've > disabled TPM module in BIOS and system is booting normally. > > There must be some kind of regression in tpm module I assume. BTW: F31 Live Beta Workstation is booting fine.. Maybe it's not loading tpm module.. or not trying to decrypt LUKS device.. *** Bug 1754141 has been marked as a duplicate of this bug. *** There's a proposed fix at https://lore.kernel.org/linux-efi/20190918191626.5741-1-jsnitsel@redhat.com/ . I'm waiting to see if it gets a review or ack but if not I may just bring this in by the end of the week. I'll try to get a response out of matthew and jarkko again today. Maybe I should resubmit with a more dire summary message. The following commits should resolve issues: (from git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git urgent branch) c0e71ec75e07 | 2019-09-25 | efi/tpm: only set efi_tpm_final_log_size after successful event log parsing (Jerry Snitselaar) 1f112c0544b1 | 2019-09-25 | efi/tpm: don't traverse an event log with no events (Peter Jones) 512fb49c9e54 | 2019-09-25 | efi/tpm: Don't access event->count when it isn't mapped. (Peter Jones) The problem seems to have gone away since I installed kernel 5.3.1-300.fc31.x86_64, so I guess the above fix is included in that. 5.3.1-300.fc31.x86_64 is still causing the same kernel panic on Lenovo t480s with TPM enabled. No progress here. Well I posted too soon. Just had the problem again on the Dell Latitude 7490 with 5.3.1-300.fc31.x86_64. It happened on the forth reboot with that kernel. Let's propose this as a Final blocker, criterion would be "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility...A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles." That's obviously not happening on...what, one boot out of four or so?...on affected systems. Discussed during the 2019-09-30 blocker review meeting: [0] The decision to delay the classification of this as a blocker bug and accept is as an AcceptedFreezeException was made as this is clearly worthy of an FE, we're not sure if it will affect enough systems to qualify as a blocker yet. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-09-30/f31-blocker-review.2019-09-30-16.00.txt I can confirm I also get kernel panic immediately during boot on Thinkpad T480s. Kernel panic in 3 out of 3 attempts. TPM is active by default on this laptop, which is also my case. Same issue here after upgrade from fedora 30 to 31 with following system (Thinkpad P51):
/:-------------:\ albertop@polamalu
:-------------------:: OS: Fedora 31 ThirtyOne
:-----------/shhOHbmp---:\ Kernel: x86_64 Linux 5.2.15-200.fc30.x86_64
/-----------omMMMNNNMMD ---: Uptime: 15h 33m
:-----------sMMMMNMNMP. ---: Packages: 2284
:-----------:MMMdP------- ---\ Shell: bash 5.0.7
,------------:MMMd-------- ---: Resolution: 6400x2160
:------------:MMMd------- .---: DE: GNOME
:---- oNMMMMMMMMMNho .----: WM: GNOME Shell
:-- .+shhhMMMmhhy++ .------/ WM Theme:
:- -------:MMMd--------------: GTK Theme: Adwaita-dark [GTK2/3]
:- --------/MMMd-------------; Icon Theme: Adwaita
:- ------/hMMMy------------: Font: Cantarell 11
:-- :dMNdhhdNMMNo------------; CPU: Intel Xeon E-2176M @ 12x 4.4GHz [50.0°C]
:---:sdNMMMMNds:------------: GPU: Quadro P2000
:------:://:-------------:: RAM: 2532MiB / 128739MiB
:---------------------://
However, same machine executed correctly yesterday when I tested kernel-5.3.2-300.fc30 from Test Day:2019-09-30 Kernel 5.3 Test Week (https://fedoramagazine.org/contribute-at-the-kernel-and-iot-edition-fedora-test-days/).
This it means that issue is fixed in 5.3.2.300?
Thanks
Yes, 5.3.2-300 has the commits: de0ec6491fe6 | 2019-10-02 | kernel-5.3.2-300.fc30 configs (Josh Boyer) a9a469be6888 | 2019-10-02 | tpm: only set efi_tpm_final_log_size after successful event log parsing (Jerry Snitselaar) db46d179ec97 | 2019-10-02 | efi+tpm: don't traverse an event log with no events (Peter Jones) d896420b9798 | 2019-10-02 | efi+tpm: Don't access event->count when it isn't mapped. (Peter Jones) (In reply to Jerry Snitselaar from comment #25) > Yes, 5.3.2-300 has the commits: > > de0ec6491fe6 | 2019-10-02 | kernel-5.3.2-300.fc30 configs (Josh Boyer) > a9a469be6888 | 2019-10-02 | tpm: only set efi_tpm_final_log_size after > successful event log parsing (Jerry Snitselaar) > db46d179ec97 | 2019-10-02 | efi+tpm: don't traverse an event log with no > events (Peter Jones) > d896420b9798 | 2019-10-02 | efi+tpm: Don't access event->count when it isn't > mapped. (Peter Jones) Great!. Thanks for positive feedback. FEDORA-2019-fbcb04143f has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-fbcb04143f kernel-5.3.2-300.fc31, kernel-headers-5.3.2-300.fc31 has been pushed to the Fedora 31 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-2019-fbcb04143f I tested kernel-5.3.2-300.fc30 (not fc31) with my T480s and it works fine. I can confirm the fix. 5.3.2-300.fc31.x86_64 on t480s work fine. The 5.3.2-300.fc31.x86_64 version has fixed the problem for the Dell Latitude 7490. Ten consecutive reboots with no problem. (In reply to Andrew Gaul from comment #10) > Disabling Secure Boot allows my NUC8i7BEH to boot with 5.3.0-1.fc31.x86_64. I can successfully boot with Secure Boot enabled with 5.3.2-300.fc31.x86_64. kernel-5.3.2-300.fc31, kernel-headers-5.3.2-300.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report. Clearing CommonBugs as we fixed this ahead of Final. |