Bug 1683197

Proposed as a Blocker for 30-beta by Fedora user frantisekz using the blocker tracking app because:

 The boot menu for all supported installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer or desktop and attempting to use the generic driver.

Discussed during the 2019-03-04 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria:

The boot menu for all supported installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer or desktop and attempting to use the generic driver.

We would like to have further testing to verify this behavior.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-03-04/f30-blocker-review.2019-03-04-17.03.txt

I wonder if this is related to bug 1628495. nomodeset hasn't worked on my laptop since Fedora 28, it broke at some point during Fedora 29 and in that bug we never figured out why and it was decided not a blocker because a. not enough hardware was affected b. they tended to work OK without nomodeset.

Anyway, I'm not clear what the expectation is: nomodeset should work, or if it should only work if needed as a fallback.

On my HP Spectre laptop; F29 and F30 fail to startup when nomodeset is set. However, I actually get *less* information in the journal with F30 failure than F29. In both cases there is no Xorg log produced, but at least in F29 there's a hint "Oct 19 11:02:44 flap.local gnome-shell[932]: Failed to create backend: Could not find a primary drm kms device" but there's nothing at all related to gnome-shell in the F30 case, I have no idea why it's not working nothing useful is logged that I can tell.

In both cases, switching to a shell fails unless I boot with `systemd.debug-shell=1` and then I can switch to tty9.

F29=Booting a USB stick imaged with Fedora-Workstation-Live-x86_64-29-1.2.iso
F30=Booting a USB stick imaged with Fedora-Workstation-Live-x86_64-30-20190224.n.0.iso

So this isn't a GDM issue really.  GDM just starts the display server, it doesn't have any influence on if the display server can initialize.

the native mutter backend (wayland) won't work with nomodeset, full stop.  it intrinsically depends on kernel modesetting.

xorg fallback, in theory can work in some cases, some of the time.  I don't think it can work in every case, but I'll defer to X team to decide if this is a bug in X.  Please attach journalctl output !

could there potentially be an issue here that X fallback isn't working? I believe the intention here is that passing 'nomodeset' causes X fallback to kick in automatically, but maybe that's what broke?

pretty unlikely, since comment 0 says "It doesn't make a difference if I force gdm to use Xorg."

can you boot to runlevel 3?  log into the getty and run startx ?

FTR, the intention is to have a safety boot option that works when the default graphics driver doesn't (which is unfortunately still somewhat common). It's now implemented through nomodeset (which in the past always caused Xorg to start up instead of Wayland), but it doesn't have to be. If there are options how to e.g. force llvmpipe to be used (which can be used even with Wayland), and it would be more compatible/less problematic than nomodeset, we can of course switch the implementation for that.

Part of this sounds suspiciously similar to bug https://bugzilla.redhat.com/show_bug.cgi?id=1679801, which also appeared a while back in F29, where GDM won't start on seat's that aren't tagged CanGraphical.

This patches fixes it for me:

-----
diff -up systemd-239/src/login/71-seat.rules.in.jx systemd-239/src/login/71-seat.rules.in
--- systemd-239/src/login/71-seat.rules.in.jx	2018-06-22 07:11:49.000000000 -0400
+++ systemd-239/src/login/71-seat.rules.in	2019-03-12 13:43:11.469554522 -0400
@@ -16,6 +16,9 @@ SUBSYSTEM=="graphics", KERNEL=="fb[0-9]*
 SUBSYSTEM=="drm", KERNEL=="card[0-9]*", TAG+="seat", TAG+="master-of-seat"
 SUBSYSTEM=="usb", ATTR{bDeviceClass}=="09", TAG+="seat"
 
+# allow efifb / uvesafb to be a master if KMS is disabled
+SUBSYSTEM=="graphics", KERNEL=="fb[0-9]", PROGRAM="/usr/bin/grep -qw nomodeset /proc/cmdline", TAG+="master-of-seat"
+
 # 'Plugable' USB hub, sound, network, graphics adapter
 SUBSYSTEM=="usb", ATTR{idVendor}=="2230", ATTR{idProduct}=="000[13]", ENV{ID_AUTOSEAT}="1"
 
-----

Let's continue the discussion in https://github.com/systemd/systemd/pull/11980 until something is merged upstream.

Well, something was merged upstream...

Zbigniew, since this is marked as an accepted blocker, can we get the fix backported to f30 and an update submitted? thanks!

systemd-241-3.gitc1f8ff8.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-82fd459dae

systemd-241-3.gitc1f8ff8.fc30 doesn't seem to fix the issue.

I've double-checked the "/usr/lib/udev/rules.d/71-seat.rules" file, it does indeed contain:

"SUBSYSTEM=="graphics", KERNEL=="fb[0-9]", IMPORT{cmdline}="nomodeset", TAG+="master-of-seat""

So, is it possible that this is not enough to fix it? I've tried it in VM and on bare metal. The problem persists, unchanged.

Same result here. I got the live image openQA built with the systemd update, booted it in a VM in 'basic graphics' mode, it fails just as before.

I am wondering if the 'improved' udev rule is actually valid / correct at all. The docs - https://linux.die.net/man/7/udev - are not particularly clear on what it *means* to stick an IMPORT in the middle of a 'matching' rule like this, but it's not a pattern I can see used anywhere else in any other udev rule and I'm not actually sure it's valid.

The most common pattern for using IMPORT is something like:

IMPORT{cmdline}="nomodeset"
ENV{nomodeset}=="1", TAG+="master-of-seat"

or something along those lines. You also see it as the final item after some matching conditions, like this:

SUBSYSTEMS=="pci", IMPORT{builtin}="hwdb --subsystem=pci"

but IMPORT{cmdline} never seems to be used that way, and I don't see *any* other use of IMPORT in this weird way where it seems to be trying to be a matching condition. I'm just not sure it's correct at all.

Perhaps we could try this instead?

IMPORT{cmdline}="nomodeset"
SUBSYSTEM=="graphics", KERNEL=="fb[0-9]", ENV{nomodeset}=="1", TAG+="master-of-seat"

Hum, that doesn't seem to work either.

ajax's original version doesn't seem to work either (doing all this testing in a virtio/spice VM ATM, will confirm on bare metal in a minute).

Seems the same on bare metal. Possibly of note: there *is* no /dev/fb0 (or /dev/fbanythingelse) when I boot with nomodeset, to runlevel 3 anyway. I can run 'startx' and some kind of X session starts up, doesn't use native, modesetting or fbdev drivers, does use the 'vesa' driver, and manages to display a cursor at least.

Also...I tested UEFI, on bare metal. It also doesn't seem to work - I wind up at a flashing cursor (but can switch to a VT and log in to a tty). In this case, there *is* a /dev/fb0 , and udevadm info shows it with the seat and master-of-seat tags, but...I'm still not getting to a desktop. There may be some kind of different issue there - the X log shows an error, apparently from fbdev driver, then immediately dies (apparently not trying vesa driver):

"Cannot run in framebuffer mode. Please specify busIDs          for all framebuffer devices"

HOWEVER, in a UEFI VM, the fix does seem to work - I get to GDM (autologin doesn't work).

So to summarize:

BIOS VM    - no /dev/fb0, not fixed
BIOS metal - no /dev/fb0, not fixed
UEFI VM    - /dev/fb0, FIXED
UEFI metal - /dev/fb0, not fixed (possibly a different issue, though?)

In the 'UEFI VM' case, it seems the fbdev driver works successfully.

Fedora kernel config appears to have CONFIG_FB_VESA=y but CONFIG_FB_UVESA not set. I'm not sure what the implications of that are.

> I am wondering if the 'improved' udev rule is actually valid / correct at all. The docs - https://linux.die.net/man/7/udev - are not particularly clear on what it *means* to stick an IMPORT in the middle of a 'matching' rule like this, but it's not a pattern I can see used anywhere else in any other udev rule and I'm not actually sure it's valid.

Yeah, the docs certainly could use an improvement. I looked at udevd sources to verify that IMPORT{cmdline}=... works as a conditional too.

> BIOS VM    - no /dev/fb0, not fixed
> BIOS metal - no /dev/fb0, not fixed
> UEFI VM    - /dev/fb0, FIXED
> UEFI metal - /dev/fb0, not fixed (possibly a different issue, though?)

For the first two cases, this patch has no effect.
For the fourth case, could you run 'udevadm info /dev/fb0'? If it has 'master-of-seat' in TAGS, then the issue is something else.

> Fedora kernel config appears to have CONFIG_FB_VESA=y but CONFIG_FB_UVESA not set. I'm not sure what the implications of that are.

The docs for FB_UVESA say:
          This is the frame buffer driver for generic VBE 2.0 compliant
          graphic cards. It can also take advantage of VBE 3.0 features,
          such as refresh rate adjustment.

          This driver generally provides more features than vesafb but
          requires a userspace helper application called 'v86d'. See
          <file:Documentation/fb/uvesafb.txt> for more information.

          If unsure, say N.

It doesn't sound like we need this, but who knows.

"For the fourth case, could you run 'udevadm info /dev/fb0'? If it has 'master-of-seat' in TAGS, then the issue is something else."

I already did that:

"In this case, there *is* a /dev/fb0 , and udevadm info shows it with the seat and master-of-seat tags, but...I'm still not getting to a desktop."

"It doesn't sound like we need this, but who knows."

I was looking at because of the comment in the original patch from ajax:

"# allow efifb / uvesafb to be a master if KMS is disabled"

note 'uvesafb' there.

systemd-241-3.gitc1f8ff8.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-82fd459dae

https://koji.fedoraproject.org/koji/taskinfo?taskID=33608156 is a kernel build with CONFIG_FB_UVESA=m, in case anyone else wants to test that.

That's no use, because we don't have the helper (/sbin/v86d) - nothing in Fedora seems to include it. Without it, the module doesn't load.

So, we are now only a few days from the first Beta go/no-go, so this is putting the Beta release at risk. Zbigniew, Adam, will it be possible to come up with a fix in the next day or two?

I'm sorry, but my knowledge about graphics drivers is nil.

Currently, I don't think this is a systemd bug (after the master-of-seat patch has been merged). The only change in systemd that I'm aware of was not to set the tag, and now we've effectively reverted it in this case.

I'm getting even worse results than adamw:
> UEFI VM    - /dev/fb0, FIXED

I see /dev/fb0 with :seat:master-of-seat:, but gnome-shell on X fails to start with "(EE) Screen(s) found, but none have a usable configuration.". I get the same result with "glx" and "VGA". I *do* get a display with "virtio" graphics.

Hmmmmm, when I *remove* xorg-x11-drv-qxl and xorg-x11-drv-vesa, to force xorg-x11-drv-fbdev to be used, I get a screen (both "qxl" and "VGA" cases).
So it seems that the hand-off from qxl to fbdev X driver is not working. I'll reassign to get more info.

Maybe "vesa" and "qxl" drivers should blacklist themselves if "nomodeset" is present on the kernel command line?

Created attachment 1545576 [details]
Xorg log with QXL virtual hardware (bad)

Created attachment 1545578 [details]
Xorg log with QXL virtual hardware with vesa driver uninstalled (bad)

Created attachment 1545579 [details]
Xorg log with QXL virtual hardware with vesa and qxl drivers uninstalled (good)

Created attachment 1545580 [details]
Xorg log with virtio virtual hardware (good)

Created attachment 1545581 [details]
Xorg log with VGA virtual hardware (bad)

Created attachment 1545582 [details]
Xorg log with VGA virtual hardware with qxl driver uninstalled (bad)

Created attachment 1545583 [details]
Xorg log with VGA virtual hardware with qxl and vesa drivers uninstalled (good)

vesa is supposed to work with nomodeset, I think.

For the record, everyone who tested on F29 reported failure of 'basic graphics' to work (IIRC), but F29 cannot have had this bug at least at release, because it had a systemd build from July 2018 and the systemd commit that stops tagging framebuffer devices as master-of-seat was only merged in October 2018. I verified that an F29 original release live image marks /dev/fb0 as master-of-seat...but nomodeset still doesn't work, in a BIOS VM. On that F29 live image, it *does* work in a UEFI VM...

I guess the fact that there's no /dev/fb0 at all in a BIOS 'nomodeset' boot could still be the problem in f29? When did the GNOME stack actually start needing something to be 'master-of-seat' before it would start up at all?

OK, answering my own question here: it in fact only does that in Fedora, I think, because it's done by this patch:

https://src.fedoraproject.org/rpms/gdm/blob/master/f/0001-local-display-factory-defer-initialization-for-CanGr.patch

which has never been merged upstream, it exists as a merge request:

https://gitlab.gnome.org/GNOME/gdm/merge_requests/37

but there's been extensive discussion of it and it has not yet been merged.

Per https://gitlab.gnome.org/GNOME/gdm/merge_requests/37#note_436062 , Ubuntu instead uses a hacky 'solution' which waits either until a master-of-seat device appears, or for ten seconds, then proceeds. So they would not have this problem.

Ray, could we modify the gdm patch to do something like Canonical's hack - if it waits ten seconds and no seat shows up as CanGraphical, just go ahead anyway and try?

i'm tempted to drop the patch entirely for now.

it's not upstream yet, and clearly causing problems.

I don't even remember why i put it in early before it got upstreamed, and my commit message is pretty terse:

commit f517b81933bfa55c904da9c02daef61e99247109
Author: Ray Strode <rstrode>
Date:   Sat Oct 6 09:46:25 2018 -0400
    - Fix login screen for machines that boot to fast

I didn't even spell too right...

Well, at least before doing that I'd be curious to look into Ubuntu's workaround and see why they introduced that. Perhaps they did actually run into a real-world case where this was a problem?

FWIW I can't get BIOS nomodeset to work in a VM even with the gdm patch reverted. With virtio graphics, it fails in X with the fb-based drivers failing to find a device (obviously) and vesa driver saying it's ignoring a device with a bound kernel module. qxl graphics fails in gnome-shell with "Failed to create backend: No GPUs found with udev". 'vga' graphics fails the same way as qxl.

Just tested bare metal: it also hit the "No GPUs found with udev" error.

The "No GPUs found with udev" error appears to come from mutter, specifically, this commit:

https://gitlab.gnome.org/GNOME/mutter/commit/1def09904763fa36d3b388924ee5c9cb6702ba8c

It looks like that can't deal with how things look with 'nomodeset' either, so that probably needs fixing too before 'nomodeset' on BIOS would work.

At the Fedora 30 Beta go/no-go meeting today:

https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2019-03-21/f30-beta-go_no_go-meeting.2019-03-21-17.00.html

it was agreed that 'basic graphics mode' has lowered in importance significantly that it should no longer block Beta releases. We will decide later whether to bump the requirement to Final or remove it entirely, but as it was agreed that the requirement will no longer be in effect at Beta, this bug is now rejected as a Beta blocker.

For now I'll put it on the proposed Final blocker list, and also propose it as a Beta FE in case of further slips.

(In reply to Adam Williamson from comment #44)
> FWIW I can't get BIOS nomodeset to work in a VM even with the gdm patch
> reverted.

Some time ago I believe it was Ajax who told me that nomodeset is not supposed to be used in VMs, but only on bare metal. So I suggest only testing this on bare metal machines, otherwise we might see a lot of confusing behavior which is not relevant for the end user anyway.

It did work with a VM and F28, I believe.

So halfline and I dug a bit further into the failures I found even with the CanGraphical stuff reverted, and we know what's going wrong there too. I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1691909 for that problem.

Discussed during the 2019-03-25 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedFreezeException" was made as we see this as being sufficiently serious to accept as an FE (and cannot be fixed with an update), but any fix may be dangerous so we may not ultimately decide to pull one in if the situation arises. We also vote to delay the classification of this as a blocker based on recent Final Blocker criteria changes that may occur. We will wait until the criteria situation is sorted and then look at this bug.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-03-25/f30-blocker-review.2019-03-25-16.01.txt

systemd-241-3.gitc1f8ff8.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

Reopening as the systemd update does not fix the BIOS case here.

Discussed during the 2019-04-01 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria:

"The boot menu for all supported installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer or desktop and attempting to use the generic driver" 

Note that this criterion was voted to be moved into the Final criteria.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-04-01/f30-blocker-review.2019-04-01-16.00.txt

I'm a bit confused here. The original issue that was discovered was the lack of udev tags,
and the title reflects that:
> gdm fails to start with "nomodeset" on BIOS installs due to lack of framebuffer / master-of-seat device
But the tags have been added back.

#1691909 is
> GDM fallback from Wayland to X11 no longer works because it takes too long to start gnome-shell

Do we need both bugs open?

Zbigniew: yes. The problem this bug is still tracking is that things still don't work on BIOS because the 'fix' assumed there would be a framebuffer device to get the tags, but there isn't; Fedora kernel does not use uvesafb, so when booting on BIOS with nomodeset, there is no framebuffer device. So GDM still does not start up in that case. In the case of a UEFI boot, the fix *does* work, because there *is* a framebuffer device to get tagged in that case.

The problem 1691909 is tracking is a subsequent bug I discovered by testing a scratch build of GDM with the patch that triggers *this* bug reverted. It turns out that even with that patch gone (so the master-of-seat stuff just isn't an issue any more), there's a timing issue with X11 fallback. That problem isn't anything for you to worry about, though, it is purely within GDM.

To be clear again, it may well be that systemd can't do anything more here - it can't tag a non-existent device, after all. That's why the bug is currently assigned to GDM - on the basis that what GDM is trying to do here may just not be viable, and it may be necessary to implement something like the hack that Ubuntu is described as having (where it waits 10 seconds for a master-of-seat device to show up, but if one doesn't, just goes ahead anyway), or just drop this effort to wait for a master-of-seat device entirely.

i'll probably drop the CanGraphical patch for now.  We'll look into it either tomorrow or monday.

okay i'm doing a build with the CanGraphical patch dropped.

Yeah, gdm-3.32.0-2.fc30 fixed the nomodeset boot on UEFI.

I've tested this on AMD GPU, I'll do some more testing on different HW later today.

Thanks!

Hello, 

I have tested the new "gdm" (version 3.32.0.2) on my machine and it could not boot with "nomodeset" in UEFI mode. 

lspci -nn | grep VGA:
-------------------------
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 Graphics] [1002:130f] (rev d4)
-------------------------

journalctl -b:
-------------------------
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) FBDEV: driver for framebuffer: fbdev
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) VESA: driver for VESA chipsets: vesa
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) [KMS] drm report modesetting isn't supported.
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (EE) open /dev/dri/card0: No such file or directory
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (WW) Falling back to old probe method for modesetting
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (EE) open /dev/dri/card0: No such file or directory
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) Loading sub module "fbdevhw"
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) LoadModule: "fbdevhw"
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
Apr 15 15:54:13 localhost.localdomain kernel: Lockdown: Xorg: ioperm is restricted; see man kernel_lockdown.7
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) Module fbdevhw: vendor="X.Org Foundation"
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]:         compiled for 1.20.4, module version = 0.0.2
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]:         ABI class: X.Org Video Driver, version 24.0
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (EE) Unable to find a valid framebuffer device
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (WW) Falling back to old probe method for fbdev
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) Loading sub module "fbdevhw"
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) LoadModule: "fbdevhw"
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) Module fbdevhw: vendor="X.Org Foundation"
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]:         compiled for 1.20.4, module version = 0.0.2
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]:         ABI class: X.Org Video Driver, version 24.0
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) FBDEV(3): using default device
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (EE) Screen 0 deleted because of no matching config section.
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) UnloadModule: "radeon"
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (EE) Screen 0 deleted because of no matching config section.
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) UnloadModule: "modesetting"
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (EE) Screen 0 deleted because of no matching config section.
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) UnloadModule: "fbdev"
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (II) UnloadSubModule: "fbdevhw"
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (EE)
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: Fatal server error:
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (EE) Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (EE)
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: Please consult the Fedora Project support
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]:          at http://wiki.x.org
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]:  for help.
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (EE)
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: (EE) Server terminated with error (1). Closing log file.
Apr 15 15:54:13 localhost.localdomain /usr/libexec/gdm-x-session[1232]: Unable to run X server
Apr 15 15:54:13 localhost.localdomain gdm-launch-environment][1222]: pam_unix(gdm-launch-environment:session): session closed for user gdm
Apr 15 15:54:13 localhost.localdomain gdm[1011]: Child process -1232 was already dead.
-------------------------------------------------------------------------------------------

So, the AMD GPU where it works is:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 6570/7570/8550] [1002:6759]

Also, GNOME Control Center crashes right after opening Displays tab while booted with nomodeset, see: https://bugzilla.redhat.com/show_bug.cgi?id=1699975

Another machine where it does not work:

00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0152] (rev 09)

journalctl -b | grep EE:
---------------------------
Apr 15 16:31:07 localhost.localdomain /usr/libexec/gdm-x-session[1236]:         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
Apr 15 16:31:07 localhost.localdomain /usr/libexec/gdm-x-session[1236]: (EE) open /dev/dri/card0: No such file or directory
Apr 15 16:31:07 localhost.localdomain /usr/libexec/gdm-x-session[1236]: (EE) open /dev/dri/card0: No such file or directory
Apr 15 16:31:07 localhost.localdomain /usr/libexec/gdm-x-session[1236]: (EE) Unable to find a valid framebuffer device
Apr 15 16:31:07 localhost.localdomain /usr/libexec/gdm-x-session[1236]: (EE) Screen 0 deleted because of no matching config section.
Apr 15 16:31:07 localhost.localdomain /usr/libexec/gdm-x-session[1236]: (EE) Screen 0 deleted because of no matching config section.
Apr 15 16:31:07 localhost.localdomain /usr/libexec/gdm-x-session[1236]: (EE)
Apr 15 16:31:07 localhost.localdomain /usr/libexec/gdm-x-session[1236]: (EE) Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices
Apr 15 16:31:07 localhost.localdomain /usr/libexec/gdm-x-session[1236]: (EE)
Apr 15 16:31:07 localhost.localdomain /usr/libexec/gdm-x-session[1236]: (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
Apr 15 16:31:07 localhost.localdomain /usr/libexec/gdm-x-session[1236]: (EE)
Apr 15 16:31:07 localhost.localdomain /usr/libexec/gdm-x-session[1236]: (EE) Server terminated with error (1). Closing log file.
---------------------------

Guys, guys, we're getting confused. :D

Dropping the 'CanGraphical' patch should have the effect of solving the problem where GDM just refuses to even try and start a graphical environment until a 'master-of-seat' device appears. It should solve this problem *for both UEFI and BIOS*. The earlier attempted fix for this bug in systemd, systemd-241-3.gitc1f8ff8.fc30 , only fixed it *on UEFI*, which is why this bug was still open.

So the expected difference with gdm-3.32.0-2.fc30 is not "this should now work better on UEFI", but "this should now work sometimes on BIOS where before it never did".

If you get to the point where you see "Cannot run in framebuffer mode" (or any *other* error from gdm-x-session), that actually proves that you're *not* hitting this bug, because this bug happens way *earlier* than that.

So, let's be really clear. We have *THREE* bugs open for nomodeset-related issues ATM.

1. #1683197 (THIS BUG) - this bug is for GDM not even attempting to start a graphical environment due to no 'master-of-seat' device showing up. The symptoms for this are boot to a black screen with no TTYs available, and no X errors or anything like that in the logs.

2. #1693409 - this bug is for the "Cannot run in framebuffer mode" error. If you are seeing that error in the logs, this is your bug.

3. #1691909 - this bug is for the expected fallback from Wayland to X not being done by GDM because the Wayland session start attempt takes longer than 3 seconds. If you see errors from an attempted Wayland session start - usually "Failed to create backend: No GPUs found with udev" - but no subsequent attempt to start an X session, i.e. no messages from 'gdm-x-session', this is probably your bug.

Let me know if any of that is not clear, sorry for the confusion :)

gdm-3.32.0-3.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-de11d64b9e

gdm-3.32.0-3.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-de11d64b9e

gdm-3.32.0-3.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

Let's wait until new gdm shows up in the next Live image compose and then do another round of verification on our devices.

The situation I'd expect at this point is that things should be substantially improved when booting in BIOS mode. In UEFI mode, lots of systems are still likely to run into https://bugzilla.redhat.com/show_bug.cgi?id=1693409 .

Honestly I think this bug should be closed, though, because this bug literally cannot exist in the new gdm build: the patch that introduced the 'master-of-seat' check was removed. That check just is not there any more. Thus it cannot possibly still cause problems.

You're using some forbidden words :-) OK, let's close it. I just wanted to make sure we wouldn't forget to verify the current state.

*** Bug 1679801 has been marked as a duplicate of this bug. ***