Created attachment 1615921 [details]
Capture of the panic from a camera
1. Please describe the problem:
After upgrading and rebooting into new Fedora 31 I received a kernel panic
On a Lenovo T480s laptop.
2. What is the Version-Release number of the kernel:
3. Did it work previously in Fedora? If so, what kernel version did the issue
*first* appear? Old kernels are available for download at
I was able to boot into the previous 5.2.14-200 kernel without any issues
4. Can you reproduce this issue? If so, please provide the steps to reproduce
the issue below:
For me I just need to reboot into the 5.3.0-git kernel
5. Does this problem occur with the latest Rawhide kernel? To install the
Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
``sudo dnf update --enablerepo=rawhide kernel``:
Will add in a subsequent comment once tested.
6. Are you running any modules that not shipped with directly Fedora's kernel?:
No. Panic is at the start of the boot (see screenshot)
7. Please attach the kernel logs. You can get the complete kernel log
for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
issue occurred on a previous boot, use the journalctl ``-b`` flag.
Panic occurs before logging.
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.
Product Name: 20L8S2N80D
Version: ThinkPad T480s
Wake-up Type: Power Switch
SKU Number: LENOVO_MT_20L8_BU_Think_FM_ThinkPad T480s
Family: ThinkPad T480s
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://firstname.lastname@example.org/ . 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: 
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.
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):
:-------------------:: 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 18.104.22.1680?
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.