Bug 2067151 - Basic graphics mode broken for X11 (GNOME/KDE/netinst) on UEFI
Summary: Basic graphics mode broken for X11 (GNOME/KDE/netinst) on UEFI
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://ask.fedoraproject.org/t/commo...
Depends On:
Blocks: F36FinalBlocker 2022385
TreeView+ depends on / blocked
 
Reported: 2022-03-23 12:18 UTC by Kamil Páral
Modified: 2022-04-13 08:18 UTC (History)
27 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-04-13 08:18:32 UTC
Type: Bug


Attachments (Terms of Use)
system journal when KDE X11 session goes black screen on BIOS (362.08 KB, text/plain)
2022-03-23 12:18 UTC, Kamil Páral
no flags Details
Xorg.0.log when KDE X11 session goes black screen on BIOS (64.77 KB, text/plain)
2022-03-23 12:18 UTC, Kamil Páral
no flags Details
rpm -qa output (62.90 KB, text/plain)
2022-03-23 12:19 UTC, Kamil Páral
no flags Details
lspci output (2.88 KB, text/plain)
2022-03-23 12:19 UTC, Kamil Páral
no flags Details
system journal when GNOME X11 session fails to start on UEFI nomodeset (549.25 KB, text/plain)
2022-03-23 17:22 UTC, Kamil Páral
no flags Details
system journal when KDE Live fails to start on UEFI nomodeset (247.39 KB, text/plain)
2022-03-30 09:46 UTC, Kamil Páral
no flags Details
system journal when netinst X11 session fails to start on UEFI nomodeset (389.63 KB, text/plain)
2022-03-31 14:22 UTC, Kamil Páral
no flags Details
Xorg log when netinst X11 session fails to start on UEFI nomodeset (6.11 KB, text/plain)
2022-03-31 14:22 UTC, Kamil Páral
no flags Details
system journal (Xorg from c42, GNOME) (17.06 KB, text/plain)
2022-04-06 14:47 UTC, Kamil Páral
no flags Details
system journal (Xorg from c48, GNOME) (17.48 KB, text/plain)
2022-04-07 17:05 UTC, Kamil Páral
no flags Details
X.Log (11.42 KB, text/plain)
2022-04-12 11:33 UTC, stefan
no flags Details

Description Kamil Páral 2022-03-23 12:18:12 UTC
Description of problem:
Note: Part of this bug was split into bug 2070130. The remaining issue is:

When F36 GNOME/KDE/netinst is booted in UEFI mode using basic graphics driver (nomodeset), X11 session is completely broken, doesn't even start. For KDE, this means the Live image doesn't even boot into graphics (because SDDM runs on X11). For GNOME, this works fine by default (it runs on Wayland), but breaks in the same way once you decide to log in using X11 session (or if you fall back to X11 by default, which might happen for certain hardware configurations, I guess). For netinst, Anaconda fails to start the graphical interface and falls back to text mode.

See comment 6 and onward for discussions related to this problem, and especially comment 25 and onward.

The hardware used is Thinkpad T480s with:
00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07)

Version-Release number of selected component (if applicable):
Fedora-KDE-Live-x86_64-36_Beta-1.4.iso
Fedora-Workstation-Live-x86_64-36_Beta-1.4.iso
xorg-x11-server-Xorg-1.20.14-4.fc36.x86_64
xorg-x11-drv-vesa-2.5.0-2.fc36.x86_64
kwin-5.24.3-3.fc36.x86_64

How reproducible:
always

Steps to Reproduce:
1. start F36 Beta KDE in basic graphics mode using UEFI
2. no graphical login, just a black screen

or
1. install F36 Beta Workstation in basic graphics mode using UEFI
2. in the installed system, try to log in using X11 session
3. get returned back to gdm immediately

or
1. start F36 Beta Everything netinst in basic graphics mode using UEFI
2. no graphical installer, falls back to a text mode

Comment 1 Kamil Páral 2022-03-23 12:18:49 UTC
Created attachment 1867785 [details]
system journal when KDE X11 session goes black screen on BIOS

Comment 2 Kamil Páral 2022-03-23 12:18:55 UTC
Created attachment 1867786 [details]
Xorg.0.log when KDE X11 session goes black screen on BIOS

Comment 3 Kamil Páral 2022-03-23 12:19:07 UTC
Created attachment 1867787 [details]
rpm -qa output

Comment 4 Kamil Páral 2022-03-23 12:19:13 UTC
Created attachment 1867788 [details]
lspci output

Comment 5 Kamil Páral 2022-03-23 12:23:34 UTC
The screen going black seems to start with this line in the journal:
bře 23 13:03:42 localhost-live akonadi_mailmerge_agent[1740]: The X11 connection broke (error 1). Did the X11 server die?

But I don't see any further details about this issue, neither in journal nor in Xorg.log.

Comment 6 Kamil Páral 2022-03-23 12:58:55 UTC
On the same laptop, I also tested running KDE in basic graphics mode in UEFI mode (including Secure Boot). That doesn't even boot into the Live image. When it seems like the display manager should start, it's forever waiting for something, so you either see a black screen or the console output (depending if you booted with rhgb). The system is not stuck though, and a power button press (or ctrl+alt+delete I guess) can make it shut down properly. I don't know if this related to the issue in comment 0 or separate, I can file it separately, if preferred.

I also tested GNOME on the same laptop. Both UEFI mode (plus Secure Boot) and BIOS mode works without issues. So this shouldn't be hardware-related.

I wonder if this F36 Change could be involved, perhaps somehow incompatible with KDE way of handling things?
https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers

Comment 7 Kamil Páral 2022-03-23 13:01:21 UTC
Proposing as a Final blocker:
"The generic video driver option ('basic graphics mode' - as described in the Basic criteria) on all release-blocking installer and live images must function as intended (launching the installer or desktop and attempting to use a generic driver), and there must be no bugs that clearly prevent the installer or desktop from being reached in this configuration on all systems or on wide classes of hardware. "
https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#.27Basic_graphics_mode.27_boot_mode_behavior

Comment 8 Kamil Páral 2022-03-23 16:25:54 UTC
On the same laptop, I also tested F35 KDE. Both under BIOS and UEFI they work fine, so this is an F36 regression. I'm working on collecting more data, stay tuned.

Comment 9 Kamil Páral 2022-03-23 17:19:08 UTC
Here's a summary of all systems tested under basic graphics mode and how they behave:

F35 KDE BIOS - no issues, X11 session, /proc/fb is empty
F35 KDE EFI - no issues, X11 session, /proc/fb contains '0 EFI VGA'
F36 GNOME BIOS - no issues, X11 session, /proc/fb is empty
F36 GNOME EFI - no issues, Wayland session, /proc/fb contains '0 simpledrmdrmfb'
              - when I try to switch to X11 session, it immediately returns back to gdm, i.e. X11 session is broken and can't be started (!!)
F36 KDE BIOS - black screen after a few minutes, X11 session, /proc/fb is empty
F36 KDE EFI - Live image doesn't boot, graphics session doesn't start


So, in addition to F36 KDE being broken universally (in basic graphics mode), X11 is also broken in GNOME, but only on EFI, which is very interesting.

Comment 10 Kamil Páral 2022-03-23 17:22:18 UTC
Created attachment 1867931 [details]
system journal when GNOME X11 session fails to start on UEFI nomodeset

Comment 11 Geraldo Simião 2022-03-23 20:59:19 UTC
I tested Fedora-Workstation-Live-x86_64-36_Beta-1.4.iso and running in BIOS mode at KVM and QXL video driver, basic graphics mode worked fine, after some seconds waiting.

Comment 12 Geraldo Simião 2022-03-23 21:00:01 UTC
(In reply to Geraldo Simião from comment #11)
> I tested Fedora-Workstation-Live-x86_64-36_Beta-1.4.iso and running in BIOS
> mode at KVM and QXL video driver, basic graphics mode worked fine, after
> some seconds waiting.

Sorry, Fedora-KDE-Live-x86_64-36_Beta-1.4.iso not workstation

Comment 13 Geraldo Simião 2022-03-23 22:31:42 UTC
So, after two hours working at the VM here, (Fedora-KDE-Live-x86_64-36_Beta-1.4.iso installed on a F35 kde plasma-wayland session) bios and qxl video, basic graphics mode, the video realy goes bad. Just the window I was working "survived" but all other graphics goes black and I ended shutting down the VM.

Comment 14 Javier Martinez Canillas 2022-03-24 08:23:41 UTC
(In reply to Kamil Páral from comment #10)
> Created attachment 1867931 [details]
> system journal when GNOME X11 session fails to start on UEFI

It seems these are the relevant bits from your log:

Mar 23 17:32:52 localhost-live systemd[1586]: Starting org.gnome.Shell@x11.service - GNOME Shell on X11...
Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell@x11.service: Skipped due to 'exec-condition'.
Mar 23 17:32:52 localhost-live systemd[1586]: Condition check resulted in org.gnome.Shell@x11.service - GNOME Shell on X11 being skipped.
Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell@x11.service: Scheduled restart job, restart counter is at 1.
Mar 23 17:32:52 localhost-live gnome-session[1698]: gnome-session-binary[1698]: GnomeDesktop-WARNING: Could not create transient scope for PID 1727: GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Process with ID 1727 does not exist.
Mar 23 17:32:52 localhost-live gnome-session-binary[1698]: GnomeDesktop-WARNING: Could not create transient scope for PID 1727: GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Process with ID 1727 does not exist.
Mar 23 17:32:52 localhost-live systemd[1586]: app-glib-liveinst\x2dsetup-1729.scope: Couldn't move process 1729 to requested cgroup '/user.slice/user-1000.slice/user@1000.service/app.slice/app-glib-liveinst\x2dsetup-1729.scope': No such process
Mar 23 17:32:52 localhost-live systemd[1586]: app-glib-liveinst\x2dsetup-1729.scope: Failed to add PIDs to scope's control group: No such process
Mar 23 17:32:52 localhost-live systemd[1586]: app-glib-liveinst\x2dsetup-1729.scope: Failed with result 'resources'.
Mar 23 17:32:52 localhost-live systemd[1586]: Failed to start app-glib-liveinst\x2dsetup-1729.scope - Application launched by gnome-session-binary.
Mar 23 17:32:52 localhost-live systemd[1586]: app-glib-xdg\x2duser\x2ddirs-1727.scope: Couldn't move process 1727 to requested cgroup '/user.slice/user-1000.slice/user@1000.service/app.slice/app-glib-xdg\x2duser\x2ddirs-1727.scope': No such process
Mar 23 17:32:52 localhost-live systemd[1586]: app-glib-xdg\x2duser\x2ddirs-1727.scope: Failed to add PIDs to scope's control group: No such process
Mar 23 17:32:52 localhost-live systemd[1586]: app-glib-xdg\x2duser\x2ddirs-1727.scope: Failed with result 'resources'.
Mar 23 17:32:52 localhost-live systemd[1586]: Failed to start app-glib-xdg\x2duser\x2ddirs-1727.scope - Application launched by gnome-session-binary.
Mar 23 17:32:52 localhost-live systemd[1586]: app-gnome-liveinst\x2dsetup-1729.scope: Couldn't move process 1729 to requested cgroup '/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-liveinst\x2dsetup-1729.scope': No such process
Mar 23 17:32:52 localhost-live systemd[1586]: app-gnome-liveinst\x2dsetup-1729.scope: Failed to add PIDs to scope's control group: No such process
Mar 23 17:32:52 localhost-live systemd[1586]: app-gnome-liveinst\x2dsetup-1729.scope: Failed with result 'resources'.
Mar 23 17:32:52 localhost-live systemd[1586]: Failed to start app-gnome-liveinst\x2dsetup-1729.scope - Application launched by gnome-session-binary.
Mar 23 17:32:52 localhost-live systemd[1586]: Stopped org.gnome.Shell@x11.service - GNOME Shell on X11.
Mar 23 17:32:52 localhost-live systemd[1586]: Starting org.gnome.Shell@x11.service - GNOME Shell on X11...
Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell@x11.service: Skipped due to 'exec-condition'.
Mar 23 17:32:52 localhost-live systemd[1586]: Condition check resulted in org.gnome.Shell@x11.service - GNOME Shell on X11 being skipped.
Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell@x11.service: Scheduled restart job, restart counter is at 2.
Mar 23 17:32:52 localhost-live systemd[1586]: Stopped org.gnome.Shell@x11.service - GNOME Shell on X11.
Mar 23 17:32:52 localhost-live systemd[1586]: Starting org.gnome.Shell@x11.service - GNOME Shell on X11...
Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell@x11.service: Skipped due to 'exec-condition'.
Mar 23 17:32:52 localhost-live systemd[1586]: Condition check resulted in org.gnome.Shell@x11.service - GNOME Shell on X11 being skipped.
Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell@x11.service: Scheduled restart job, restart counter is at 3.
Mar 23 17:32:52 localhost-live systemd[1586]: Stopped org.gnome.Shell@x11.service - GNOME Shell on X11.
Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell@x11.service: Start request repeated too quickly.
Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell@x11.service: Skipped due to 'exec-condition'.
Mar 23 17:32:52 localhost-live systemd[1586]: Started org.gnome.Shell@x11.service - GNOME Shell on X11.
...
Mar 23 17:32:52 localhost-live systemd[1586]: Reached target gnome-session-initialized.target - GNOME Session is initialized.
Mar 23 17:32:52 localhost-live systemd[1586]: gnome-session-x11-services.target - GNOME session X11 services is inactive.
Mar 23 17:32:52 localhost-live systemd[1586]: Dependency failed for org.gnome.SettingsDaemon.XSettings.service - GNOME XSettings service.
Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.SettingsDaemon.XSettings.service: Job org.gnome.SettingsDaemon.XSettings.service/start failed with result 'dependency'.
Mar 23 17:32:52 localhost-live systemd[1586]: gnome-session-x11-services-ready.target: Job gnome-session-x11-services-ready.target/verify-active failed with result 'dependency'.
Mar 23 17:32:52 localhost-live systemd[1586]: Reached target gnome-session@gnome.target - GNOME Session (session: gnome).

Comment 15 Kamil Páral 2022-03-24 08:48:43 UTC
(In reply to Geraldo Simião from comment #11)
> I tested Fedora-Workstation-Live-x86_64-36_Beta-1.4.iso and running in BIOS mode at KVM

Geraldo, basic video driver can't be tested in a VM. This needs to be tested on bare metal only.

(In reply to Javier Martinez Canillas from comment #14)
> It seems these are the relevant bits from your log:

Javier, do you think the KDE issues and the GNOME issue is related, or should I file the GNOME one into a separate bug report?

Comment 16 Javier Martinez Canillas 2022-03-24 11:05:42 UTC
(In reply to Kamil Páral from comment #15)
> (In reply to Geraldo Simião from comment #11)
> > I tested Fedora-Workstation-Live-x86_64-36_Beta-1.4.iso and running in BIOS mode at KVM
> 
> Geraldo, basic video driver can't be tested in a VM. This needs to be tested
> on bare metal only.
> 
> (In reply to Javier Martinez Canillas from comment #14)
> > It seems these are the relevant bits from your log:
> 
> Javier, do you think the KDE issues and the GNOME issue is related, or
> should I file the GNOME one into a separate bug report?

I don't know to be honest. Someone more familiar with GNOME sessions should chime in.

Comment 17 Geoffrey Marr 2022-03-28 19:44:25 UTC
Discussed during the 2022-03-28 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:

"The generic video driver option...must function as intended (launching the installer or desktop and attempting to use a generic driver), and there must be no bugs that clearly prevent the installer or desktop from being reached in this configuration on all systems or on wide classes of hardware".

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-03-28/f36-blocker-review.2022-03-28-16.00.txt

Comment 18 Michel Dänzer 2022-03-29 08:57:46 UTC
(In reply to Kamil Páral from comment #9)
> F36 GNOME BIOS - no issues, X11 session, /proc/fb is empty
> F36 GNOME EFI - no issues, Wayland session, /proc/fb contains '0 simpledrmdrmfb'

Javier, any idea why simpledrm isn't active when booting without EFI? (I thought it might be due to nomodeset, but then the question becomes why simpledrm is active when booting with EFI :)

Comment 19 Javier Martinez Canillas 2022-03-29 13:12:43 UTC
(In reply to Michel Dänzer from comment #18)
> (In reply to Kamil Páral from comment #9)
> > F36 GNOME BIOS - no issues, X11 session, /proc/fb is empty
> > F36 GNOME EFI - no issues, Wayland session, /proc/fb contains '0 simpledrmdrmfb'
> 
> Javier, any idea why simpledrm isn't active when booting without EFI? (I
> thought it might be due to nomodeset, but then the question becomes why
> simpledrm is active when booting with EFI :)

I think it is expected, since the simpledrm driver only supports the VIDEO_TYPE_VLFB
(VESA VGA in graphic mode) and VIDEO_TYPE_EFI (EFI graphic mode) as defined in
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/screen_info.h#L54

Non-VESA VGA modes are handled by the vgacon driver and VIDEO_TYPE_VLFB is only set
if a "vga=" kernel command line parameter is used. In that case, the vesafb fbdev
driver is probed.

In other words, these are the possible drivers used depending on the firmware and
kernel command line parameters used:

1- F35 BIOS with no custom parameters:

   vgacon -> fbcon on top of the fbdev emulated by the real DRM driver.

   In this case no /dev/fb0 exists but a /dev/dri/card0 exists.

2- F35 BIOS with vga=$mode (where $mode is a VESA VGA mode, i.e: 794).

   vgacon -> dummycon -> fbcon on top of the vesafb fbdev

   In this case both a /dev/fb0 (vesafb) and /dev/dri/card0 (real DRM driver) exists.

3- F35 BIOS with vga=$mode and nomodeset

   vgacon -> dummycon -> fbcon on top of the vesafb fbdev.

   In this case a /dev/fb0 (vesafb) exists but no /dev/dri/card0 (the real DRM driver won't probe due nomodeset).

4- F35 BIOS with nomodeset

   vgacon.

   In this case neither a /dev/fb0 (no vesafb due missing vga=) nor /dev/dri/card0 (real DRM driver won't probe due nomodeset) exists.

   This will also make the graphical.target to fail since GDM won't be able to start, the /var/log/Xorg.0.log shows:

   ...
   [    16.371] (EE) open /dev/dri/card0: No such file or directory
   [    16.371] (WW) Falling back to old probe method for modesetting
   [    16.371] (EE) open /dev/dri/card0: No such file or directory
   [    16.371] (II) Loading sub module "fbdevhw"
   [    16.371] (II) LoadModule: "fbdevhw"
   [    16.371] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
   [    16.371] (II) Module fbdevhw: vendor="X.Org Foundation"
   [    16.372]    compiled for 1.20.11, module version = 0.0.2
   [    16.372]    ABI class: X.Org Video Driver, version 24.1
   [    16.372] (EE) Unable to find a valid framebuffer device
   [    16.372] (WW) Falling back to old probe method for fbdev
   [    16.372] (II) Loading sub module "fbdevhw"
   [    16.372] (II) LoadModule: "fbdevhw"
   [    16.372] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
   [    16.372] (II) Module fbdevhw: vendor="X.Org Foundation"
   [    16.372]    compiled for 1.20.11, module version = 0.0.2
   [    16.372]    ABI class: X.Org Video Driver, version 24.1
   [    16.372] (EE) open /dev/fb0: No such file or directory
   [    16.372] vesa: Ignoring device with a bound kernel driver
   [    16.372] (EE) Screen 0 deleted because of no matching config section.
   [    16.372] (II) UnloadModule: "modesetting"
   [    16.372] (EE) Screen 0 deleted because of no matching config section.
   [    16.372] (II) UnloadModule: "fbdev"
   [    16.372] (II) UnloadSubModule: "fbdevhw"
   [    16.372] (EE) Screen 0 deleted because of no matching config section.
   [    16.372] (II) UnloadModule: "vesa"
   [    16.372] (EE) Device(s) detected, but none match those in the config file.
   [    16.372] (EE)
   Fatal server error:
   [    16.372] (EE) no screens found(EE)
   ...

5- F35 EFI with no custom parameters:

   fbcon on top of the efifb fbdev

   In this case both a /dev/fb0 (efifb) and /dev/dri/card0 (real DRM driver) exists.

6- F35 EFI with nomodeset

   fbcon on top of the efifb fbdev

   In this case a /dev/fb0 (efifb) exists but no /dev/dri/card0 (the real DRM driver won't probe due nomodeset).


Note how for EFI we always have a fbdev but that's not the case for BIOS, that's
only the case when using a "vga=" param which will make vesafb driver to be used.

It is the same for F36 with simpledrm, the driver will only be probed when using
a "vga=" param and setting the video mode to VESA VGA instead of VGA+.

That is, the goal of simpledrm is to replace efifb and vesafb, but not to cover
the case when no fbdev was used (only vgacon instead of fbcon on top of a fbdev).

Comment 20 Michel Dänzer 2022-03-29 13:53:41 UTC
(In reply to Javier Martinez Canillas from comment #19)
> 
> 4- F35 BIOS with nomodeset
> 
>    vgacon.
> 
>    In this case neither a /dev/fb0 (no vesafb due missing vga=) nor
> /dev/dri/card0 (real DRM driver won't probe due nomodeset) exists.
> 
>    This will also make the graphical.target to fail since GDM won't be able
> to start, the /var/log/Xorg.0.log shows:
[...]
>    [    16.372] vesa: Ignoring device with a bound kernel driver

This says there's an active kernel graphics driver, which shouldn't be the case with nomodeset on F35.

According to comment 9, this case works fine on F35 (I failed to take this into account for my previous comment).

It seems like there's been some kind of regression between KDE / Xorg / the Xorg vesa driver. (Or possibly Mesa, if KDE uses OpenGL in this case)

Comment 21 Kamil Páral 2022-03-29 15:20:03 UTC
(In reply to Michel Dänzer from comment #20)
> >    [    16.372] vesa: Ignoring device with a bound kernel driver
> 
> This says there's an active kernel graphics driver, which shouldn't be the
> case with nomodeset on F35.

Javier was testing in a VM with SeaBIOS, that might have affected things? QA never tests basic graphics mode in VMs, because we know they behave differently from bare metal. All results provided in comment 9 were tested on bare metal (Thinkpad T480s). Javier asked me to additionally provide contents of /dev/fb0 and /dev/dri/card0 for each case, I'll do that tomorrow.

Comment 22 Javier Martinez Canillas 2022-03-29 19:37:40 UTC
(In reply to Kamil Páral from comment #21)
> (In reply to Michel Dänzer from comment #20)
> > >    [    16.372] vesa: Ignoring device with a bound kernel driver
> > 
> > This says there's an active kernel graphics driver, which shouldn't be the
> > case with nomodeset on F35.
>

I was confused by that too. But as mentioned there wasn't neither a /dev/fb0
nor /dev/dri/card0 on that VM when booting with "nomodeset".
 
> Javier was testing in a VM with SeaBIOS, that might have affected things? QA
> never tests basic graphics mode in VMs, because we know they behave
> differently from bare metal. All results provided in comment 9 were tested
> on bare metal (Thinkpad T480s). Javier asked me to additionally provide
> contents of /dev/fb0 and /dev/dri/card0 for each case, I'll do that tomorrow.

Just a clarification, I didn't ask for the content but whether the devices exists.

Comment 23 Neal Gompa 2022-03-30 00:38:02 UTC
(In reply to Michel Dänzer from comment #20)
> (In reply to Javier Martinez Canillas from comment #19)
> > 
> > 4- F35 BIOS with nomodeset
> > 
> >    vgacon.
> > 
> >    In this case neither a /dev/fb0 (no vesafb due missing vga=) nor
> > /dev/dri/card0 (real DRM driver won't probe due nomodeset) exists.
> > 
> >    This will also make the graphical.target to fail since GDM won't be able
> > to start, the /var/log/Xorg.0.log shows:
> [...]
> >    [    16.372] vesa: Ignoring device with a bound kernel driver
> 
> This says there's an active kernel graphics driver, which shouldn't be the
> case with nomodeset on F35.
> 
> According to comment 9, this case works fine on F35 (I failed to take this
> into account for my previous comment).
> 
> It seems like there's been some kind of regression between KDE / Xorg / the
> Xorg vesa driver. (Or possibly Mesa, if KDE uses OpenGL in this case)

KDE Plasma always uses OpenGL by default in Fedora.

We also haven't touched anything the KDE Plasma code with X11 (and indeed the same X11 session with the same Plasma version works in F35).

Comment 24 Kamil Páral 2022-03-30 09:46:41 UTC
Created attachment 1869299 [details]
system journal when KDE Live fails to start on UEFI nomodeset

Comment 25 Kamil Páral 2022-03-30 09:50:29 UTC
When running basic graphics mode (nomodeset) on different OSes using bare metal (Thinkpad T480s):

F35 GNOME BIOS
- no issues with Live and installed system
- X11 session
- /proc/fb is empty
- /dev/fb0 doesn't exist
- /dev/dri/card0 doesn't exist

F35 GNOME EFI
- no issues with Live and installed system
- X11 session
- /proc/fb contains '0 EFI VGA'
- /dev/fb0 exists
- /dev/dri/card0 doesn't exist

F35 KDE BIOS
- no issues with Live and installed system
- X11 session
- /proc/fb is empty
- /dev/fb0 doesn't exist
- /dev/dri/card0 doesn't exist

F35 KDE EFI
- no issues with Live and installed system
- X11 session
- /proc/fb contains '0 EFI VGA'
- /dev/fb0 exists
- /dev/dri/card0 doesn't exist

F36 Beta GNOME BIOS
- no issues with Live and installed system
- X11 session
- /proc/fb is empty
- /dev/fb0 doesn't exist
- /dev/dri/card0 doesn't exist

F36 Beta GNOME EFI
- no issues with Live and installed system *by default*
- Wayland session
- /proc/fb contains '0 simpledrmdrmfb'
- /dev/fb0 exists
- /dev/dri/card0 exists
- when I try to switch to X11 session on the installed system, it immediately returns back to gdm, i.e. X11 session is broken and can't be started (!!). See comment 10 for logs.

F36 Beta KDE BIOS
- no issues with Live image
- black screen after a few minutes on the installed system (!!). See comment 1 through comment 5 for logs.
- X11 session
- /proc/fb is empty
- /dev/fb0 doesn't exist
- /dev/dri/card0 doesn't exist

F36 Beta KDE EFI
- Live image doesn't fully boot - graphics session doesn't start (!!). (You can switch to tty2 using Ctrl+Alt+F2 and log in as 'liveuser' in the text mode, for debugging). See comment 24 for logs.
- /proc/fb contains '0 simpledrmdrmfb'  (in a text console)
- /dev/fb0 exists  (in a text console)
- /dev/dri/card0 exists  (in a text console)

Comment 26 Javier Martinez Canillas 2022-03-30 12:01:23 UTC
Thanks a lot Kamil for all this information.

(In reply to Kamil Páral from comment #25)
> When running basic graphics mode (nomodeset) on different OSes using bare
> metal (Thinkpad T480s):
> 
> F35 GNOME BIOS
> - no issues with Live and installed system
> - X11 session
> - /proc/fb is empty
> - /dev/fb0 doesn't exist
> - /dev/dri/card0 doesn't exist
>

I was confused how it worked in this case but Michael explained to me that
the X server uses the xf86-video-vesa Xorg driver that just calls into the
VESA APIs in the VBIOS.

But this driver is only loaded if there isn't a driver bound to the device
registered for the graphics card.
 
> F35 GNOME EFI
> - no issues with Live and installed system
> - X11 session
> - /proc/fb contains '0 EFI VGA'
> - /dev/fb0 exists
> - /dev/dri/card0 doesn't exist
>

That's expected, the X server uses the xf86-video-fbdev Xorg driver on top
of the efifb fbdev driver.

> F35 KDE BIOS
> - no issues with Live and installed system
> - X11 session
> - /proc/fb is empty
> - /dev/fb0 doesn't exist
> - /dev/dri/card0 doesn't exist
>

That's expected, the X server uses the xf86-video-vesa Xorg driver.
 
> F35 KDE EFI
> - no issues with Live and installed system
> - X11 session
> - /proc/fb contains '0 EFI VGA'
> - /dev/fb0 exists
> - /dev/dri/card0 doesn't exist
>

That's expected, the X server uses the xf86-video-fbdev Xorg driver on top
of the efifb fbdev driver.
 
> F36 Beta GNOME BIOS
> - no issues with Live and installed system
> - X11 session
> - /proc/fb is empty
> - /dev/fb0 doesn't exist
> - /dev/dri/card0 doesn't exist
>

That's expected, the X server uses the xf86-video-vesa Xorg driver.
 
> F36 Beta GNOME EFI
> - no issues with Live and installed system *by default*
> - Wayland session
> - /proc/fb contains '0 simpledrmdrmfb'
> - /dev/fb0 exists
> - /dev/dri/card0 exists
> - when I try to switch to X11 session on the installed system, it
> immediately returns back to gdm, i.e. X11 session is broken and can't be
> started (!!). See comment 10 for logs.
>

Right it only works because GDM is starting a Wayland session by default
but it does not when trying an X11 session. From the log in Comment 10,
the following lines seems relevant:

Mar 23 17:33:55 localhost-live /usr/libexec/gdm-x-session[3548]: (EE) open /dev/fb0: Permission denied
Mar 23 17:33:55 localhost-live /usr/libexec/gdm-x-session[3548]: (II) modeset(G0): using drv /dev/dri/card0
Mar 23 17:33:55 localhost-live /usr/libexec/gdm-x-session[3548]: (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
 
> F36 Beta KDE BIOS
> - no issues with Live image
> - black screen after a few minutes on the installed system (!!). See comment
> 1 through comment 5 for logs.
> - X11 session
> - /proc/fb is empty
> - /dev/fb0 doesn't exist
> - /dev/dri/card0 doesn't exist
>

I don't know why it has this black screen after a few minutes but it should just be
a X server using the xf86-video-vesa driver as is the case for F36 Beta GNOME BIOS.

I believe this is a separate issue.

> F36 Beta KDE EFI
> - Live image doesn't fully boot - graphics session doesn't start (!!). (You
> can switch to tty2 using Ctrl+Alt+F2 and log in as 'liveuser' in the text
> mode, for debugging). See comment 24 for logs.
> - /proc/fb contains '0 simpledrmdrmfb'  (in a text console)
> - /dev/fb0 exists  (in a text console)
> - /dev/dri/card0 exists  (in a text console)

The X server logs in Comment 24 show the same error than in the case for
F36 Beta GNOME EFI. But the Wayland session not working seems to be yet
another separate issue.

(EE) open /dev/fb0: Permission denied\n(II) modeset(G0): using drv /dev/dri/card0
(WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
(EE) Screen 0 deleted because of no matching config section.
(II) UnloadModule: \"modesetting\"\n(EE) Screen 1 deleted

So in summary we have 3 separate issues I believe:

1) A X11 session not starting with simpledrm with both F36 Beta GNOME and KDE

2) A Wayland session not starting with simpledrm with F36 Beta KDE

3) A black screen after a few minutes in a X11 session with F36 Beta KDE BIOS

Comment 27 Kamil Páral 2022-03-30 12:57:28 UTC
> 1) A X11 session not starting with simpledrm with both F36 Beta GNOME and KDE
> 2) A Wayland session not starting with simpledrm with F36 Beta KDE

These two might actually be the same. Sddm was recently reverted back to X11 for F36, and while it should be skipped by autologin, it looks likely that it still affects the boot process and breaks the graphical session. This is further supported by the fact that I tested Fedora-KDE-Live-x86_64-Rawhide-20220324.n.1.iso where the X11 revert didn't happen (i.e. sddm still runs on Wayland), and I can boot that image. It boots into sddm (although that should be skipped by autologin), and there's X11 and Wayland session selection. X11 is chosen by default, and if you try to log in, it behaves exactly the same as with F36 Beta GNOME EFI - it immediately returns back to sddm. A Wayland session can be started and works.

So it seems we only have one issue here - X11 being broken in F36 UEFI with nomodeset, both on GNOME and KDE. Just on KDE, it breaks it completely due to sddm still running on X11.

> 3) A black screen after a few minutes in a X11 session with F36 Beta KDE BIOS

I'll file a separate bug for this.

Comment 28 Neal Gompa 2022-03-30 13:09:40 UTC
(In reply to Kamil Páral from comment #27)
> > 1) A X11 session not starting with simpledrm with both F36 Beta GNOME and KDE
> > 2) A Wayland session not starting with simpledrm with F36 Beta KDE
> 
> These two might actually be the same. Sddm was recently reverted back to X11
> for F36, and while it should be skipped by autologin, it looks likely that
> it still affects the boot process and breaks the graphical session. This is
> further supported by the fact that I tested
> Fedora-KDE-Live-x86_64-Rawhide-20220324.n.1.iso where the X11 revert didn't
> happen (i.e. sddm still runs on Wayland), and I can boot that image. It
> boots into sddm (although that should be skipped by autologin), and there's
> X11 and Wayland session selection. X11 is chosen by default, and if you try
> to log in, it behaves exactly the same as with F36 Beta GNOME EFI - it
> immediately returns back to sddm. A Wayland session can be started and works.
> 
> So it seems we only have one issue here - X11 being broken in F36 UEFI with
> nomodeset, both on GNOME and KDE. Just on KDE, it breaks it completely due
> to sddm still running on X11.
> 

This is correct. We still pass through SDDM, which initializes the greeter before handing off to autologin.

Comment 29 Javier Martinez Canillas 2022-03-30 13:23:30 UTC
(In reply to Kamil Páral from comment #27)
> > 1) A X11 session not starting with simpledrm with both F36 Beta GNOME and KDE
> > 2) A Wayland session not starting with simpledrm with F36 Beta KDE
> 
> These two might actually be the same. Sddm was recently reverted back to X11
> for F36, and while it should be skipped by autologin, it looks likely that
> it still affects the boot process and breaks the graphical session. This is
> further supported by the fact that I tested
> Fedora-KDE-Live-x86_64-Rawhide-20220324.n.1.iso where the X11 revert didn't
> happen (i.e. sddm still runs on Wayland), and I can boot that image. It
> boots into sddm (although that should be skipped by autologin), and there's
> X11 and Wayland session selection. X11 is chosen by default, and if you try
> to log in, it behaves exactly the same as with F36 Beta GNOME EFI - it
> immediately returns back to sddm. A Wayland session can be started and works.
> 
> So it seems we only have one issue here - X11 being broken in F36 UEFI with
> nomodeset, both on GNOME and KDE. Just on KDE, it breaks it completely due
> to sddm still running on X11.
>

BTW, it's not only F36 UEFI with nomodeset but also F36 BIOS with nomodeset *and*
setting a VESA VGA mode with vga=$mode.

I was able to reproduce it on a F36 BIOS VM with a virtio GPU device and following
kernel command line parameters "nomodeset vga=792". An X11 session fails to start.
 
> > 3) A black screen after a few minutes in a X11 session with F36 Beta KDE BIOS
> 
> I'll file a separate bug for this.

Great, thanks.

Comment 30 Kamil Páral 2022-03-30 13:33:45 UTC
(In reply to Kamil Páral from comment #27)
> > 3) A black screen after a few minutes in a X11 session with F36 Beta KDE BIOS
> 
> I'll file a separate bug for this.

Split into bug 2070130, and this bug's description has been adjusted to cover just 1).

Comment 31 stefan 2022-03-31 11:41:21 UTC
So the problem occurs laptops or desktop pc with Nvdia 
cards. Under Amd graphics cards the iso starts without problem

tested with 



Fedora-Everything-netinst-x86_64-36-20220331.n.0.iso      
Fedora-Workstation-Live-x86_64-36-20220331.n.0.iso       
Fedora-KDE-Live-x86_64-36-20220331.n.0.iso

Comment 32 Kamil Páral 2022-03-31 14:20:55 UTC
It's a great idea to test netinst, I didn't realize I should try it as well. It uses a minimal X11 environment. I can confirm on my T480s it behaves exactly like KDE and GNOME described above, i.e. it fails to start on UEFI with nomodeset. Anaconda prints out

> X or window manager startup failed, falling back to text mode.

I'll attach logs.

(In reply to stefan from comment #31)
> So the problem occurs laptops or desktop pc with Nvdia 
> cards. Under Amd graphics cards the iso starts without problem
Stefan, are you sure you used UEFI and nomodeset when testing? So far I only tested on Intel, but I'll make sure to test at least Live images on AMD hardware as well.

Comment 33 Kamil Páral 2022-03-31 14:22:03 UTC
Created attachment 1869708 [details]
system journal when netinst X11 session fails to start on UEFI nomodeset

Comment 34 Kamil Páral 2022-03-31 14:22:34 UTC
Created attachment 1869709 [details]
Xorg log when netinst X11 session fails to start on UEFI nomodeset

Comment 35 Kamil Páral 2022-03-31 14:38:33 UTC
I tested KDE Live and netinst on AMD Radeon 580 graphics, and I experience exactly the same issues as with my Intel GPU setup. (I didn't test GNOME because that would require an installation). X11 doesn't start with nomodeset, and it does start OK without it.

Comment 36 Neal Gompa 2022-04-03 22:19:19 UTC
Can folks try this scratch build? https://koji.fedoraproject.org/koji/taskinfo?taskID=85124690

Comment 37 Vicente Salvador 2022-04-04 00:20:45 UTC
I installed this scratch build (using --nodeps because some weird dependency incompatibility between sddm-x11 and sddm-wayland-generic) and it works in my laptop.

Congratulations, it seams this new build fixes the issue.

Comment 38 Kamil Páral 2022-04-04 09:54:56 UTC
(In reply to Neal Gompa from comment #36)
> Can folks try this scratch build?
> https://koji.fedoraproject.org/koji/taskinfo?taskID=85124690

Neal, how is a sddm update supposed to fix an issue that affects all of gnome+kde+netinst? Either way, I tested it just to make sure if it at least somehow works around the problem. It doesn't. It's still as broken as before (comment 0).

What I did:
1. Installed F36 KDE Beta on UEFI without nomodeset
2. Verified that boot breaks with nomodeset
3. Updated sddm
4. Checked that it boots OK without nomodeset and still breaks with nomodeset
5. Fully updated the system
6. Checked that it boots OK without nomodeset and still breaks with nomodeset

Comment 39 stefan 2022-04-04 10:19:10 UTC
(In reply to Kamil Páral from comment #32)
> It's a great idea to test netinst, I didn't realize I should try it as well.
> It uses a minimal X11 environment. I can confirm on my T480s it behaves
> exactly like KDE and GNOME described above, i.e. it fails to start on UEFI
> with nomodeset. Anaconda prints out
> 
> > X or window manager startup failed, falling back to text mode.
> 
> I'll attach logs.
> 
> (In reply to stefan from comment #31)
> > So the problem occurs laptops or desktop pc with Nvdia 
> > cards. Under Amd graphics cards the iso starts without problem
> Stefan, are you sure you used UEFI and nomodeset when testing? So far I only
> tested on Intel, but I'll make sure to test at least Live images on AMD
> hardware as well.



Kamil Páral you were right I forgot to set nomodeset :(

Comment 40 stefan 2022-04-04 10:21:37 UTC
(In reply to Neal Gompa from comment #36)
> Can folks try this scratch build?
> https://koji.fedoraproject.org/koji/taskinfo?taskID=85124690

The problem still exists !
getest mit Fedora-Everything-netinst-x86_64-36-20220404.n.0.iso

Comment 41 Neal Gompa 2022-04-04 18:16:44 UTC
(In reply to Kamil Páral from comment #38)
> (In reply to Neal Gompa from comment #36)
> > Can folks try this scratch build?
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=85124690
> 
> Neal, how is a sddm update supposed to fix an issue that affects all of
> gnome+kde+netinst? Either way, I tested it just to make sure if it at least
> somehow works around the problem. It doesn't. It's still as broken as before
> (comment 0).
> 
> What I did:
> 1. Installed F36 KDE Beta on UEFI without nomodeset
> 2. Verified that boot breaks with nomodeset
> 3. Updated sddm
> 4. Checked that it boots OK without nomodeset and still breaks with nomodeset
> 5. Fully updated the system
> 6. Checked that it boots OK without nomodeset and still breaks with nomodeset

I'm just trying to reduce the scope of problem spaces. This at least confirms that sddm isn't the problem for this one to me (it's our X11 hotpath).

Comment 42 Adam Jackson 2022-04-05 14:59:17 UTC
For reference, in RHEL9, 'nomodeset' means no graphics for you. vesa is bad, fbdev is bad, nobody should be using them, and in particular _we_ should not expose a path to them through the installer, let alone consider such a path to be a release blocker. In my arrogant but probably correct opinion, anyway.

But since we've decided to do bad things, let's see if this works:

https://koji.fedoraproject.org/koji/taskinfo?taskID=85207923

The patch in that build disables the "platform" (ie DRM) probe code when 'nomodeset' is given on the kernel command line, since it's not going to work in any case. This should at least make things fail in new and interesting ways...

Comment 43 Neal Gompa 2022-04-05 16:59:14 UTC
(In reply to Adam Jackson from comment #42)
> For reference, in RHEL9, 'nomodeset' means no graphics for you. vesa is bad,
> fbdev is bad, nobody should be using them, and in particular _we_ should not
> expose a path to them through the installer, let alone consider such a path
> to be a release blocker. In my arrogant but probably correct opinion, anyway.
> 

I wish we had a "drm.force_simple" option to use instead for basic graphics mode.

But alas, we don't, and we're stuck with "nomodeset", which is a horrible option we should not use.

Comment 44 Javier Martinez Canillas 2022-04-05 17:39:21 UTC
(In reply to Neal Gompa from comment #43)
> (In reply to Adam Jackson from comment #42)
> > For reference, in RHEL9, 'nomodeset' means no graphics for you. vesa is bad,
> > fbdev is bad, nobody should be using them, and in particular _we_ should not
> > expose a path to them through the installer, let alone consider such a path
> > to be a release blocker. In my arrogant but probably correct opinion, anyway.
> > 
> 
> I wish we had a "drm.force_simple" option to use instead for basic graphics
> mode.
> 

Yeah, I proposed a "drm.disable_native_drivers" param but that was nacked:

https://www.spinics.net/lists/kernel/msg4121522.html

> But alas, we don't, and we're stuck with "nomodeset", which is a horrible
> option we should not use.

It's meaning have changed over the years but at least now we have it documented:

https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html

        nomodeset       Disable kernel modesetting. DRM drivers will not perform
                        display-mode changes or accelerated rendering. Only the
                        system framebuffer will be available for use if this was
                        set-up by the firmware or boot loader.

Comment 45 Jocelyn Falempe 2022-04-05 17:41:32 UTC
(In reply to Adam Jackson from comment #42)

> 
> But since we've decided to do bad things, let's see if this works:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=85207923
> 

I tested this build, but I still have the same Xorg error :(

[  4961.923] (EE) 
Fatal server error:
[  4961.923] (EE) Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices

Comment 46 Kamil Páral 2022-04-06 14:38:21 UTC
(In reply to Adam Jackson from comment #42)
> For reference, in RHEL9, 'nomodeset' means no graphics for you. vesa is bad,
> fbdev is bad, nobody should be using them, and in particular _we_ should not
> expose a path to them through the installer, let alone consider such a path
> to be a release blocker. In my arrogant but probably correct opinion, anyway.

Adam, just because the things are the way they are doesn't mean they can't be changed. You probably know more about this stuff than most, so if you believe we should get rid of "basic graphics mode", please make a proposal on devel list and let's discuss it. On a QA level, we test it because the boot menu item is there. It is a release blocker probably since forever, because it probably made sense to people back then. Also, it used to be much more common to have graphics driver issues in the past. Things can be changed, even now, shortly before F36 Final. But it must be initiated by people with expertise.

I'll try test the new Koji build shortly.

Comment 47 Kamil Páral 2022-04-06 14:47:57 UTC
Created attachment 1871103 [details]
system journal (Xorg from c42, GNOME)

(In reply to Adam Jackson from comment #42)
> https://koji.fedoraproject.org/koji/taskinfo?taskID=85207923

Attached is the journal output which occurs when I try to log in to GNOME X11 session (nomodeset, UEFI) using the modified Xorg from comment 42.

Comment 48 Jocelyn Falempe 2022-04-07 09:45:32 UTC
I have made a small hack to make it work :

https://gitlab.freedesktop.org/jocelyn/xserver/-/commit/f45376239a4ae00ce65a010b23aae25e57243b45#2a6fbf7a9cb589c5421c85084d0ea8b159bd0447

But this needs more work to have something acceptable.

I've launched a koji build with this hack:
https://koji.fedoraproject.org/koji/taskinfo?taskID=85292112

Comment 49 Kamil Páral 2022-04-07 17:05:55 UTC
Created attachment 1871366 [details]
system journal (Xorg from c48, GNOME)

(In reply to Jocelyn Falempe from comment #48)
> I've launched a koji build with this hack:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=85292112

Didn't work for me. Log is attached.

Comment 50 Jocelyn Falempe 2022-04-07 20:51:02 UTC
(In reply to Kamil Páral from comment #49)
> Created attachment 1871366 [details]
> system journal (Xorg from c48, GNOME)
> 
> (In reply to Jocelyn Falempe from comment #48)
> > I've launched a koji build with this hack:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=85292112
> 
> Didn't work for me. Log is attached.

ok I see the problem:

dub 07 19:04:04 fenix /usr/libexec/gdm-x-session[1566]: (EE) open /dev/fb0: Permission denied

I think I also added my user to the video group:

sudo usermod -a -G video "my_user"

Comment 51 Kamil Páral 2022-04-08 07:43:11 UTC
(In reply to Jocelyn Falempe from comment #50)
> I think I also added my user to the video group:

Do you want me to do that, and provide a log again, in order to help debugging? (We of course need some solution that doesn't require manual intervention).

Comment 52 Jocelyn Falempe 2022-04-08 08:12:45 UTC
(In reply to Kamil Páral from comment #51)
> (In reply to Jocelyn Falempe from comment #50)
> > I think I also added my user to the video group:
> 
> Do you want me to do that, and provide a log again, in order to help
> debugging? (We of course need some solution that doesn't require manual
> intervention).

No it's not a good solution anyway. It uses the framebuffer device, and we want Xorg to use the drm driver (without hw acceleration/modesetting) instead.

Comment 53 Jocelyn Falempe 2022-04-08 14:58:13 UTC
I think I found the culprit:

We are missing this patch :
https://gitlab.freedesktop.org/xorg/xserver/-/commit/b9218fadf3c09d83566549279d68886d8258f79c

I've started a koji build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=85357623

if you can confirm it solves the issue for you ?

Comment 54 Adam Williamson 2022-04-09 09:25:58 UTC
On the "why is it there / a blocker" issue - we've had this discussion many times, each time a bug comes up on this area. I think we did tall about taking the criterion out last time it came up (maybe 34 or 35?) but decided against it. The list archives should have the discussion I think.

Comment 55 František Zatloukal 2022-04-09 22:07:30 UTC
(In reply to Jocelyn Falempe from comment #53)
> I think I found the culprit:
> 
> We are missing this patch :
> https://gitlab.freedesktop.org/xorg/xserver/-/commit/
> b9218fadf3c09d83566549279d68886d8258f79c
> 
> I've started a koji build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=85357623
> 
> if you can confirm it solves the issue for you ?

The scratch build/patch fixed the issue, tested on KDE Spin / UEFI nomodeset.

Comment 56 Kamil Páral 2022-04-11 08:26:43 UTC
(In reply to Jocelyn Falempe from comment #53)
> I've started a koji build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=85357623

And I confirmed using GNOME UEFI nomodeset. Everything will need to wait until we create a compose with it, that's the easiest approach.

Great work, Jocelyn! Can anyone please create a proper build and a Bodhi update?

Comment 57 Fedora Update System 2022-04-11 09:41:17 UTC
FEDORA-2022-06c6ca0e70 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-06c6ca0e70

Comment 58 Fedora Update System 2022-04-11 14:57:37 UTC
FEDORA-2022-06c6ca0e70 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-06c6ca0e70`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-06c6ca0e70

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 59 Fedora Update System 2022-04-11 22:52:21 UTC
FEDORA-2022-06c6ca0e70 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 60 Kamil Páral 2022-04-12 07:16:40 UTC
We will still want to verify this with a new compose of Everything netinst and KDE Live (see comment 0). Setting ON_QA.

Comment 61 stefan 2022-04-12 09:47:48 UTC
with today's iso Fedora-Everything-netinst-x86_64-36-20220412.n.0.iso still not working

Problem
falls back to a text mode

Comment 62 Kamil Páral 2022-04-12 10:02:35 UTC
Stefan, I tested with the same image and it works fine for me (UEFI, nomodeset), graphical anaconda starts. Please provide system logs (/tmp/X.log, /tmp/syslog).
KDE Live is not built yet, I'll test it once it is.

Comment 63 stefan 2022-04-12 11:21:47 UTC
my X.log


[    25.362] (WW) Failed to open protocol names file /usr/lib64/xorg/protocol.txt
[    25.362] 
X.Org X Server 1.20.14
X Protocol Version 11, Revision 0
[    25.362] Build Operating System:  5.16.18-200.fc35.x86_64 
[    25.362] Current Operating System: Linux fedora 5.17.2-300.fc36.x86_64 #1 SMP PREEMPT Fri Apr 8 14:35:55 UTC 2022 x86_64
[    25.362] Kernel command line: BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-E-dvd-x86_64-36 quiet nomodeset
[    25.362] Build Date: 08 April 2022  12:00:00AM
[    25.362] Build ID: xorg-x11-server 1.20.14-5.fc36 
[    25.362] Current version of pixman: 0.40.0
[    25.362] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[    25.362] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    25.362] (++) Log file: "/tmp/X.log", Time: Tue Apr 12 13:11:38 2022
[    25.365] (==) Using config directory: "/etc/X11/xorg.conf.d"
[    25.365] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[    25.372] (==) No Layout section.  Using the first Screen section.
[    25.372] (==) No screen section available. Using defaults.
[    25.372] (**) |-->Screen "Default Screen Section" (0)
[    25.372] (**) |   |-->Monitor "<default monitor>"
[    25.372] (==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
[    25.372] (==) Automatically adding devices
[    25.372] (==) Automatically enabling devices
[    25.372] (==) Automatically adding GPU devices
[    25.372] (==) Automatically binding GPU devices
[    25.372] (==) Max clients allowed: 256, resource mask: 0x1fffff
[    25.372] (==) FontPath set to:
	catalogue:/etc/X11/fontpath.d,
	built-ins
[    25.372] (==) ModulePath set to "/usr/lib64/xorg/modules"
[    25.372] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[    25.372] (II) Loader magic: 0x5565d9c0daa0
[    25.372] (II) Module ABI versions:
[    25.372] 	X.Org ANSI C Emulation: 0.4
[    25.372] 	X.Org Video Driver: 24.1
[    25.372] 	X.Org XInput driver : 24.1
[    25.372] 	X.Org Server Extension : 10.0
[    25.373] (++) using VT number 6

[    25.373] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration
[    25.373] (II) xfree86: Adding drm device (/dev/dri/card0)
[    25.377] (--) PCI:*(1@0:0:0) 10de:1081:10b0:0801 rev 161, Mem @ 0xf6000000/16777216, 0xe8000000/134217728, 0xf0000000/33554432, I/O @ 0x0000e000/128, BIOS @ 0x????????/131072
[    25.378] (II) LoadModule: "glx"
[    25.379] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
[    25.398] (II) Module glx: vendor="X.Org Foundation"
[    25.398] 	compiled for 1.20.14, module version = 1.0.0
[    25.398] 	ABI class: X.Org Server Extension, version 10.0
[    25.531] (==) Matched nouveau as autoconfigured driver 0
[    25.531] (==) Matched nv as autoconfigured driver 1
[    25.531] (==) Matched modesetting as autoconfigured driver 2
[    25.531] (==) Matched fbdev as autoconfigured driver 3
[    25.531] (==) Matched vesa as autoconfigured driver 4
[    25.531] (==) Assigned the driver to the xf86ConfigLayout
[    25.531] (II) LoadModule: "nouveau"
[    25.531] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so
[    25.543] (II) Module nouveau: vendor="X.Org Foundation"
[    25.543] 	compiled for 1.20.14, module version = 1.0.17
[    25.543] 	Module class: X.Org Video Driver
[    25.543] 	ABI class: X.Org Video Driver, version 24.1
[    25.543] (II) LoadModule: "nv"
[    25.543] (WW) Warning, couldn't open module nv
[    25.543] (EE) Failed to load module "nv" (module does not exist, 0)
[    25.543] (II) LoadModule: "modesetting"
[    25.543] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
[    25.550] (II) Module modesetting: vendor="X.Org Foundation"
[    25.550] 	compiled for 1.20.14, module version = 1.20.14
[    25.550] 	Module class: X.Org Video Driver
[    25.550] 	ABI class: X.Org Video Driver, version 24.1
[    25.550] (II) LoadModule: "fbdev"
[    25.550] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so
[    25.553] (II) Module fbdev: vendor="X.Org Foundation"
[    25.553] 	compiled for 1.20.14, module version = 0.5.0
[    25.553] 	Module class: X.Org Video Driver
[    25.553] 	ABI class: X.Org Video Driver, version 24.1
[    25.553] (II) LoadModule: "vesa"
[    25.553] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so
[    25.559] (II) Module vesa: vendor="X.Org Foundation"
[    25.559] 	compiled for 1.20.14, module version = 2.5.0
[    25.559] 	Module class: X.Org Video Driver
[    25.559] 	ABI class: X.Org Video Driver, version 24.1
[    25.559] (II) NOUVEAU driver 
[    25.559] (II) NOUVEAU driver for NVIDIA chipset families :
[    25.559] 	RIVA TNT            (NV04)
[    25.559] 	RIVA TNT2           (NV05)
[    25.559] 	GeForce 256         (NV10)
[    25.559] 	GeForce 2           (NV11, NV15)
[    25.559] 	GeForce 4MX         (NV17, NV18)
[    25.559] 	GeForce 3           (NV20)
[    25.559] 	GeForce 4Ti         (NV25, NV28)
[    25.559] 	GeForce FX          (NV3x)
[    25.559] 	GeForce 6           (NV4x)
[    25.559] 	GeForce 7           (G7x)
[    25.559] 	GeForce 8           (G8x)
[    25.559] 	GeForce 9           (G9x)
[    25.559] 	GeForce GTX 2xx/3xx (GT2xx)
[    25.559] 	GeForce GTX 4xx/5xx (GFxxx)
[    25.559] 	GeForce GTX 6xx/7xx (GKxxx)
[    25.559] 	GeForce GTX 9xx     (GMxxx)
[    25.559] 	GeForce GTX 10xx    (GPxxx)
[    25.559] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[    25.559] (II) FBDEV: driver for framebuffer: fbdev
[    25.559] (II) VESA: driver for VESA chipsets: vesa
[    25.563] (EE) [drm] Failed to open DRM device for (null): -22
[    25.692] (EE) [drm] Failed to open DRM device for pci:0000:01:00.0: -19
[    25.693] (II) modeset(0): using drv /dev/dri/card0
[    25.693] (II) Loading sub module "fbdevhw"
[    25.693] (II) LoadModule: "fbdevhw"
[    25.694] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
[    25.703] (II) Module fbdevhw: vendor="X.Org Foundation"
[    25.703] 	compiled for 1.20.14, module version = 0.0.2
[    25.703] 	ABI class: X.Org Video Driver, version 24.1
[    25.703] (EE) Unable to find a valid framebuffer device
[    25.703] (WW) Falling back to old probe method for fbdev
[    25.703] (II) Loading sub module "fbdevhw"
[    25.703] (II) LoadModule: "fbdevhw"
[    25.704] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
[    25.704] (II) Module fbdevhw: vendor="X.Org Foundation"
[    25.704] 	compiled for 1.20.14, module version = 0.0.2
[    25.704] 	ABI class: X.Org Video Driver, version 24.1
[    25.704] (EE) Screen 1 deleted because of no matching config section.
[    25.704] (II) UnloadModule: "fbdev"
[    25.704] (II) UnloadSubModule: "fbdevhw"
[    25.704] (II) modeset(0): Creating default Display subsection in Screen section
	"Default Screen Section" for depth/fbbpp 24/32
[    25.704] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
[    25.704] (==) modeset(0): RGB weight 888
[    25.704] (==) modeset(0): Default visual is TrueColor
[    25.704] (II) Loading sub module "glamoregl"
[    25.704] (II) LoadModule: "glamoregl"
[    25.704] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
[    25.743] (II) Module glamoregl: vendor="X.Org Foundation"
[    25.743] 	compiled for 1.20.14, module version = 1.0.1
[    25.743] 	ABI class: X.Org ANSI C Emulation, version 0.4
[    27.436] (II) modeset(0): Refusing to try glamor on llvmpipe
[    27.440] (EE) modeset(0): glamor initialization failed
[    27.440] (II) modeset(0): ShadowFB: preferred NO, enabled NO
[    27.441] (II) modeset(0): Output None-1 has no monitor section
[    27.441] (II) modeset(0): EDID for output None-1
[    27.446] (II) modeset(0): Printing probed modes for output None-1
[    27.446] (II) modeset(0): Modeline "800x600"x60.0   28.80  800 800 800 800  600 600 600 600 (36.0 kHz eP)
[    27.446] (II) modeset(0): Output None-1 connected
[    27.446] (II) modeset(0): Using exact sizes for initial modes
[    27.446] (II) modeset(0): Output None-1 using initial mode 800x600 +0+0
[    27.446] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0)
[    27.446] (++) modeset(0): DPI set to (96, 96)
[    27.446] (II) Loading sub module "fb"
[    27.446] (II) LoadModule: "fb"
[    27.446] (II) Loading /usr/lib64/xorg/modules/libfb.so
[    27.453] (II) Module fb: vendor="X.Org Foundation"
[    27.453] 	compiled for 1.20.14, module version = 1.0.0
[    27.453] 	ABI class: X.Org ANSI C Emulation, version 0.4
[    27.453] (II) Loading sub module "vbe"
[    27.453] (II) LoadModule: "vbe"
[    27.453] (II) Loading /usr/lib64/xorg/modules/libvbe.so
[    27.456] (II) Module vbe: vendor="X.Org Foundation"
[    27.456] 	compiled for 1.20.14, module version = 1.1.0
[    27.456] 	ABI class: X.Org Video Driver, version 24.1
[    27.456] (II) Loading sub module "int10"
[    27.456] (II) LoadModule: "int10"
[    27.456] (II) Loading /usr/lib64/xorg/modules/libint10.so
[    27.460] (II) Module int10: vendor="X.Org Foundation"
[    27.460] 	compiled for 1.20.14, module version = 1.0.0
[    27.460] 	ABI class: X.Org Video Driver, version 24.1
[    27.460] (II) VESA(1): initializing int10
[    27.461] (II) VESA(1): Bad V_BIOS checksum
[    27.461] (II) VESA(1): Primary V_BIOS segment is: 0xc000
[    27.486] (II) VESA(1): VESA BIOS detected
[    27.486] (II) VESA(1): VESA VBE Version 3.0
[    27.486] (II) VESA(1): VESA VBE Total Mem: 14336 kB
[    27.486] (II) VESA(1): VESA VBE OEM: NVIDIA
[    27.486] (II) VESA(1): VESA VBE OEM Software Rev: 112.16
[    27.486] (II) VESA(1): VESA VBE OEM Vendor: NVIDIA Corporation
[    27.486] (II) VESA(1): VESA VBE OEM Product: BIOS-P/N@N7677
[    27.486] (II) VESA(1): VESA VBE OEM Product Rev: GW-CLK@lÜÐ 
[    27.535] (II) VESA(1): Creating default Display subsection in Screen section
	"Default Screen Section" for depth/fbbpp 24/32
[    27.535] (==) VESA(1): Depth 24, (--) framebuffer bpp 32
[    27.535] (==) VESA(1): RGB weight 888
[    27.535] (==) VESA(1): Default visual is TrueColor
[    27.535] (==) VESA(1): Using gamma correction (1.0, 1.0, 1.0)
[    27.535] (EE) 
[    27.535] (EE) Backtrace:
[    27.537] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x13d) [0x5565d9b79f4d]
[    27.542] (EE) 1: /lib64/libc.so.6 (__sigaction+0x50) [0x7fd16e67fac0]
[    27.543] (EE) 2: /usr/libexec/Xorg (xf86CollectOptions+0x1e4) [0x5565d9a5be64]
[    27.543] (EE) unw_get_proc_name failed: no unwind info found [-10]
[    27.543] (EE) 3: /usr/lib64/xorg/modules/drivers/vesa_drv.so (?+0x0) [0x7fd16da8b810]
[    27.543] (EE) 4: /usr/libexec/Xorg (InitOutput+0x117b) [0x5565d9a6136b]
[    27.543] (EE) 5: /usr/libexec/Xorg (miPutImage+0xb4b) [0x5565d9a06922]
[    27.544] (EE) 6: /lib64/libc.so.6 (__libc_start_call_main+0x80) [0x7fd16e66a590]
[    27.544] (EE) 7: /lib64/libc.so.6 (__libc_start_main+0x89) [0x7fd16e66a649]
[    27.544] (EE) 8: /usr/libexec/Xorg (_start+0x25) [0x5565d9a07785]
[    27.544] (EE) 
[    27.544] (EE) Segmentation fault at address 0x124
[    27.544] (EE) 
Fatal server error:
[    27.544] (EE) Caught signal 11 (Segmentation fault). Server aborting
[    27.544] (EE) 
[    27.544] (EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
[    27.544] (EE) Please also check the log file at "/tmp/X.log" for additional information.
[    27.544] (EE) 
[    27.548] (EE) Server terminated with error (1). Closing log file.

Comment 64 stefan 2022-04-12 11:33:32 UTC
Created attachment 1871943 [details]
X.Log

Comment 65 Kamil Páral 2022-04-12 11:50:00 UTC
I also tested with Fedora-KDE-Live-x86_64-36-20220412.n.0.iso now, it boots just fine (UEFI, nomodeset). Which means this problem is resolved on my hardware.

Jocelyn, Javier and others - is it possible that this problem persists on Nvidia cards? I see that Stefan has an nvidia card. Or do you think his problem is a different one?

Comment 66 stefan 2022-04-12 11:54:26 UTC
When testing under another system with amd 580 graphics card it works without problems.

Only with system with Nvidia graphics cards the problem is still present

Comment 67 Jocelyn Falempe 2022-04-12 12:36:01 UTC
(In reply to stefan from comment #66)
> When testing under another system with amd 580 graphics card it works
> without problems.
> 
> Only with system with Nvidia graphics cards the problem is still present

Are you sure you are booting in UEFI mode ?

I see the VESA driver in your Xorg.log, so I suspect it boots in legacy BIOS mode.

So I think it's a different issue with Nvidia/Bios in basic graphic mode.

Can you open another Bugzilla for this ?

Comment 68 stefan 2022-04-12 12:58:14 UTC
(In reply to Jocelyn Falempe from comment #67)
> (In reply to stefan from comment #66)
> > When testing under another system with amd 580 graphics card it works
> > without problems.
> > 
> > Only with system with Nvidia graphics cards the problem is still present
> 
> Are you sure you are booting in UEFI mode ?



it was booted in uefi mode



> I see the VESA driver in your Xorg.log, so I suspect it boots in legacy BIOS
> mode.
> 
> So I think it's a different issue with Nvidia/Bios in basic graphic mode.
> 
> Can you open another Bugzilla for this ?

what name should i use for the bug ?

Comment 69 Jocelyn Falempe 2022-04-12 13:28:29 UTC
(In reply to stefan from comment #68)

> it was booted in uefi mode

ok, maybe that should be a kind of hybrid UEFI, on one of my laptop, I have 3 choices 
1) Legacy BIOS 
2) Hybrid UEFI 
3) UEFI

If you have this options in your machine, can you try in "pure" UEFI ?
> 
> what name should i use for the bug ?

Basic graphics mode broken for X11 with Nvidia GPU

Comment 70 stefan 2022-04-12 16:46:36 UTC
(In reply to Jocelyn Falempe from comment #69)
> (In reply to stefan from comment #68)
> 
> > it was booted in uefi mode
> 
> ok, maybe that should be a kind of hybrid UEFI, on one of my laptop, I have
> 3 choices 
> 1) Legacy BIOS 
> 2) Hybrid UEFI 
> 3) UEFI
> 
> If you have this options in your machine, can you try in "pure" UEFI ?

So I can select either as  
UEFI USB 
or
Normal USB boot 

> > 
> > what name should i use for the bug ?
> 
> Basic graphics mode broken for X11 with Nvidia GPU

Comment 71 Kamil Páral 2022-04-13 06:19:26 UTC
Stefan, Jocelyn is speaking about firmware configuration. So after you press F1 or similar, get to firmware config screen, a navigate some menus to find the boot options. There you usually can switching between "Legacy" and "UEFI" mode, and also "CSM support" (which should be off in UEFI mode, I believe).

You seem to be speaking about a one-time boot selection menu. If you had UEFI mode without CSM, I think you wouldn't even see "Normal USB boot" in there.

Comment 72 stefan 2022-04-13 07:08:22 UTC
Regardless of this, one question arises ? 
Why does the f35 run without further Bios settings, even when resetting the Bios.

Especially when I install on this motherboard a graphics card AMD 580, there are also no problems. without the further settings in the bios to make.


Here is the link to the bug Basic graphics mode broken for X11 with Nvidia GPU
https://bugzilla.redhat.com/show_bug.cgi?id=2074789

Comment 73 Kamil Páral 2022-04-13 08:18:32 UTC
Thanks, Stefan. Let's discuss your nvidia-specific issue in the new bug. I'm going to close this one as resolved.


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