Bug 1936791 - Kernel 5.11 - Unable to boot beyond GRUB menu on FC33
Summary: Kernel 5.11 - Unable to boot beyond GRUB menu on FC33
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1941232 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-03-09 07:36 UTC by Ryan
Modified: 2021-04-06 14:53 UTC (History)
23 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-03-27 14:02:39 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Linux Kernel 212133 0 None None None 2021-03-09 07:36:54 UTC

Description Ryan 2021-03-09 07:36:54 UTC
1. Please describe the problem:

Unable to boot beyond GRUB boot menu

2. What is the Version-Release number of the kernel:
5.11.3-50.fc33, 5.11.4-50.fc33

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

5.10.21-200.fc33 works fine as do any previous 5.10 series kernels

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

Not just me affected by this issue, there is someone else in the test day results that is experiencing it, and the bug I have linked from the Linux Kernel bugzilla. Seems to be affecting the AMD STONEY APUs from all the reports I've seen so far.

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``:

yes

6. Are you running any modules that not shipped with directly Fedora's kernel?:

No

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.

Unable to get the kernel logs for this issue as I can't even boot into the operating system. The only option I have is to hit the power button.

Comment 1 Ryan 2021-03-09 07:42:43 UTC
Note that after the kernel is selected in the grub menu, it flicks to a white cursor on a black background. I can't hit ctrl+alt+del nor can I switch to any tty terminal. this is what i mean by 'the only option is to hit the power button'.

Comment 2 Ryan 2021-03-10 01:15:46 UTC
still an issue with 5.11.5-50.fc33

Comment 3 Ryan 2021-03-10 03:24:48 UTC
tried the options provided by the kernel team to the user in the referenced kernel bugzilla bug, nomodeset and amdgpu.dc=[0|1] makes no difference to the boot status

Comment 4 Ruslan Rudenko 2021-03-10 15:50:47 UTC
I second this, faced the same problem with both 5.11 and 5.12 (rc) kernels as well. This is clearly a regression since latest 5.10 releases (5.10.20, 5.10.21 & 5.10.22) with 5.9 and 5.8 releases worked totally fine. I also have Stoney chip in my configuration: https://linux-hardware.org/?probe=f40d786ac2

Comment 5 Ryan 2021-03-11 05:58:25 UTC
As per the attached Kernel bug, further testing on my part shows this is an issue all the way back to 5.11-rc1. I am troubleshooting with the Kernel team to try and find the commit that introduced the issue.

Comment 6 Ryan 2021-03-17 07:33:03 UTC
After further testing with the Kernel team, I can now boot 5.12-rc3 with the iommu-fixes branch of the git tree mentioned here: https://bugzilla.kernel.org/show_bug.cgi?id=212133#c23. I imagine this will be made available in an upcoming kernel release and pushed to 5.11 as well. These are specifically AMD IOMMU fixes.

Comment 7 Ryan 2021-03-18 03:30:19 UTC
I have discovered I can properly boot 5.11 series kernels with iommu=soft as per https://www.kernel.org/doc/Documentation/x86/x86_64/boot-options.txt, This means that until the fix provided by Joerg Roedel is upstreamed, we at least have a workaround.

Comment 8 Phil Seymour 2021-03-20 20:14:43 UTC
This is still an issue with 5.11.7-200 on Fedora 33

Comment 9 Gregory Lee Bartholomew 2021-03-21 19:44:06 UTC
Same here on a Lenovo Ideacentre 310S-08ASR (AMD A9-9425 CPU) running the 5.11.7-200.fc33.x86_64 kernel. Adding iommu=soft works around the problem.

Comment 10 Ryan 2021-03-21 22:18:05 UTC
Looks like the fixes are now available in 5.12-rc4, but not 5.11 yet

Comment 11 Hans de Goede 2021-03-22 09:58:09 UTC
*** Bug 1941232 has been marked as a duplicate of this bug. ***

Comment 12 Ryan 2021-03-24 23:21:14 UTC
5.11.9-200.fc33 fixes this issue (currently in Koji, soon to be in updates testing)

Comment 13 Gregory Lee Bartholomew 2021-03-26 19:59:55 UTC
5.11.9-200.fc33 has resolved the problem for me.

Comment 14 Phil Seymour 2021-03-26 21:04:16 UTC
Same as comment #13 ^^ - latest kernel 5.11.9-200 (f33 x86) has resolved the problem.

Comment 15 Arnold Boothroyd 2021-03-27 09:01:56 UTC
Essentially likewise to the two above comments: I didn't get around to updating until 5.11.10-200.fc33.x86_64 had shown up, but with it the problem has been resolved (no more need for the iommu=soft workaround).

Comment 16 Hans de Goede 2021-03-27 14:02:39 UTC
Closing this, since multiple people have confirmed that this is fixed in 5.11.9 / 5.11.10 and newer.

Comment 17 Gurenko Alex 2021-04-06 14:53:49 UTC
Interesting, I still have this happening on F34 with kernel 5.11.11, although it looks like a race as occasionally it works. 5.11.10 works consistently well.


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