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
Created attachment 1867785 [details] system journal when KDE X11 session goes black screen on BIOS
Created attachment 1867786 [details] Xorg.0.log when KDE X11 session goes black screen on BIOS
Created attachment 1867787 [details] rpm -qa output
Created attachment 1867788 [details] lspci output
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.
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
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
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.
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.
Created attachment 1867931 [details] system journal when GNOME X11 session fails to start on UEFI nomodeset
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.
(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
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.
(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 - GNOME Shell on X11... Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell: Skipped due to 'exec-condition'. Mar 23 17:32:52 localhost-live systemd[1586]: Condition check resulted in org.gnome.Shell - GNOME Shell on X11 being skipped. Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell: 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/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/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/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 - GNOME Shell on X11. Mar 23 17:32:52 localhost-live systemd[1586]: Starting org.gnome.Shell - GNOME Shell on X11... Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell: Skipped due to 'exec-condition'. Mar 23 17:32:52 localhost-live systemd[1586]: Condition check resulted in org.gnome.Shell - GNOME Shell on X11 being skipped. Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell: Scheduled restart job, restart counter is at 2. Mar 23 17:32:52 localhost-live systemd[1586]: Stopped org.gnome.Shell - GNOME Shell on X11. Mar 23 17:32:52 localhost-live systemd[1586]: Starting org.gnome.Shell - GNOME Shell on X11... Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell: Skipped due to 'exec-condition'. Mar 23 17:32:52 localhost-live systemd[1586]: Condition check resulted in org.gnome.Shell - GNOME Shell on X11 being skipped. Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell: Scheduled restart job, restart counter is at 3. Mar 23 17:32:52 localhost-live systemd[1586]: Stopped org.gnome.Shell - GNOME Shell on X11. Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell: Start request repeated too quickly. Mar 23 17:32:52 localhost-live systemd[1586]: org.gnome.Shell: Skipped due to 'exec-condition'. Mar 23 17:32:52 localhost-live systemd[1586]: Started org.gnome.Shell - 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 Session (session: gnome).
(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?
(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.
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
(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 :)
(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).
(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)
(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.
(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.
(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).
Created attachment 1869299 [details] system journal when KDE Live fails to start on UEFI nomodeset
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)
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
> 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.
(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.
(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.
(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).
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
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.
Created attachment 1869708 [details] system journal when netinst X11 session fails to start on UEFI nomodeset
Created attachment 1869709 [details] Xorg log when netinst X11 session fails to start on UEFI nomodeset
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.
Can folks try this scratch build? https://koji.fedoraproject.org/koji/taskinfo?taskID=85124690
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.
(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
(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 :(
(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
(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).
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...
(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.
(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.
(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
(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.
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.
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
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.
(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"
(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).
(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.
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 ?
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.
(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.
(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?
FEDORA-2022-06c6ca0e70 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-06c6ca0e70
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.
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.
We will still want to verify this with a new compose of Everything netinst and KDE Live (see comment 0). Setting ON_QA.
with today's iso Fedora-Everything-netinst-x86_64-36-20220412.n.0.iso still not working Problem falls back to a text mode
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.
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.
Created attachment 1871943 [details] X.Log
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?
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
(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 ?
(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 ?
(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
(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
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.
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
Thanks, Stefan. Let's discuss your nvidia-specific issue in the new bug. I'm going to close this one as resolved.