Bug 1693409

Created attachment 1548697 [details]
Full journal log from an affected boot

Note when the system first boots, gdm seems to fail for some reason that is not very well logged. I then did 'systemctl restart gdm' from a console at which point the X errors showed up.

Created attachment 1550886 [details]
journalctl of failing nvidia 1060 setup

Same error on ryzen 5 + nvidia 1060.

Same as adamw, this particular box can work properly on native mode but I suspect that newer nvidia's that don't work properly with nouveau suffer this too

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

 'Basic graphics mode' boot mode behavior

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.

It would be good if we could find a system which actually *needs* nomodeset but can't use it, to justify this being a blocker. Maybe we can send out a call for testing...

just released nvidia sounds as good candidate.

Anyhow, our just rewritten criteria does not have any limit that constraints its scope to just those setups that actually need it. We should add it if we want that, but that would be a testing challenge since we have some difficulties to find a box that actually needs it :D

"Anyhow, our just rewritten criteria does not have any limit that constraints its scope to just those setups that actually need it."

No, but there is a general policy about when bugs actually violate the criteria if they don't affect all systems:

https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F

But the bug *affects* a lot of hardware, your and mine for example. We can workaround to a working desktop using normal mode. We can discuss if the workaround is enough for sure

Discussed at 2019-04-08 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2019-04-08/ . We decided to delay the decision on this as it is not yet entirely clear what class or classes of hardware the bug affects, and we do not yet have definite proof that it affects any system where nomodeset/fallback path boot is actually needed.

It would be very useful for making a decision if the graphics devs could at least figure out the basic causation of this issue so we have some idea what hardware is affected. We will also send out a mailing list call for testing to try and get more data on affected hardware.

I hit this as originally described.

[    8.530023] flap.local /usr/libexec/gdm-x-session[1037]: (EE) Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices

kernel-5.0.6-300.fc30.x86_64
gdm-3.32.0-1.fc30.x86_64
mutter-3.32.0-2.fc30.x86_64

Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) (prog-if 00 [VGA controller])
	Subsystem: Hewlett-Packard Company Device [103c:81a0]

That's the only GPU this laptop has.

It's broken on AMD RX 580 / UEFI (CSM) with this line in journal:
(EE) Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices

lspci | grep VGA:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev e7)

Using the F30 Live iso posted to fedora-devel, it does not work on a T470s with Intel HD Graphics 620 [8086:5916] (rev 02)

The 'Cannot run in framebuffer mode' line *is* present in the log.

See https://bugzilla.redhat.com/show_bug.cgi?id=1698261 for another interesting case - the very same error in a somewhat different scenario (X startup on an ARM dev board).

I am using the ISO suggested by the Test List message from Adam, that is 20190408, and I cannot boot with nomodeset and UEFI. I ran this test on one of the office desktops, see specs.

VGA adapter:
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 Graphics] (rev d4)

Journalctl:
Apr 10 16:59:19 localhost.localdomain /usr/libexec/gdm-x-session[1253]: (EE) Screen 0 deleted because of no matching config section.
Apr 10 16:59:19 localhost.localdomain /usr/libexec/gdm-x-session[1253]: (II) UnloadModule: "fbdev"
Apr 10 16:59:19 localhost.localdomain /usr/libexec/gdm-x-session[1253]: (II) UnloadSubModule: "fbdevhw"
Apr 10 16:59:19 localhost.localdomain /usr/libexec/gdm-x-session[1253]: (EE)
Apr 10 16:59:19 localhost.localdomain /usr/libexec/gdm-x-session[1253]: Fatal server error:

Apr 10 16:59:19 localhost.localdomain /usr/libexec/gdm-x-session[1253]: (EE) Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices

Apr 10 16:59:19 localhost.localdomain /usr/libexec/gdm-x-session[1253]: (EE)
Apr 10 16:59:19 localhost.localdomain /usr/libexec/gdm-x-session[1253]: Please consult the Fedora Project support
Apr 10 16:59:19 localhost.localdomain /usr/libexec/gdm-x-session[1253]: at http://wiki.x.org
Apr 10 16:59:19 localhost.localdomain /usr/libexec/gdm-x-session[1253]: for help.
Apr 10 16:59:19 localhost.localdomain /usr/libexec/gdm-x-session[1253]: (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
Apr 10 16:59:19 localhost.localdomain /usr/libexec/gdm-x-session[1253]: (EE)
Apr 10 16:59:19 localhost.localdomain rtkit-daemon[899]: Supervising 0 threads of 0 processes of 1 users.
Apr 10 16:59:19 localhost.localdomain /usr/libexec/gdm-x-session[1253]: (EE) Server terminated with error (1). Closing log file.
Apr 10 16:59:19 localhost.localdomain /usr/libexec/gdm-x-session[1253]: Unable to run X server
Apr 10 16:59:19 localhost.localdomain gdm-launch-environment][1244]: pam_unix(gdm-launch-environment:session): session closed for user gdm
Apr 10 16:59:19 localhost.localdomain audit[1244]: USER_END pid=1244 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_close

It seems like of all the feedback we've got on the testing request so far, *no one* has seen a successful UEFI 'nomodeset' boot on a bare metal system. Everyone seems to be running into this bug. The only successful test I'm aware of was mine in a VM.

Given this, I'm adjusting the summary, and I am more inclined to think this bug is a release blocker...

Just want to add two more tested computers. The boot process was unsuccessful on both of them, showing the expected errors (this one and also that mentioned by kparal on Test List).

The computers' graphics were:

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 6570/7570/8550] [1002:6759]

and

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

Same here on a similar setup to Chris' in comment 10 (built-in Intel GPU only). I do get some permission errors due to SecureBoot-induced kernel lockdown. I'll post some logs when I get a chance to get them.

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

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

"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)..."

Current feedback indicates this affects almost all tested systems.

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

log has:

Unable to find a valid framebuffer device

that comes from this function:

fbdev_open_pci(struct pci_device *pPci, char **namep)•
{•
...
    for (i = 0; i < 8; i++) {•
        snprintf(filename, sizeof(filename),•
                 "/sys/bus/pci/devices/%04x:%02x:%02x.%d/graphics/fb%d",•
                 pPci->domain, pPci->bus, pPci->dev, pPci->func, i);•
•
        fd = open(filename, O_RDONLY, 0);•
...
        if (fd >= 0) {•
            close(fd);•
            snprintf(filename, sizeof(filename), "/dev/fb%d", i);•
•
            fd = open(filename, O_RDWR, 0);•
            if (fd != -1) {•
                if (ioctl(fd, FBIOGET_FSCREENINFO, (void *) &fix) != -1) {•
                    if (namep) {•
                        *namep = xnfalloc(16);•
                        strncpy(*namep, fix.id, 16);•
                    }•
•
                    return fd;•
...
        }•
    }•
...
    xf86DrvMsg(-1, X_ERROR, "Unable to find a valid framebuffer device\n");•
    return -1;•
}•

So I guess the problem is one of three possibilities:

1) /sys/bus/pci/devices/%04x:%02x:%02x.%d/graphics/fb0 doesn't exist or is unreadable
2) /dev/fb0 doesn't exist or is unreadable
3) FBIOGET_FSCREENINFO ioctl is failing

does booting with enforcing=0 make things work?  Can someone do:

$ stat /sys/bus/pci/devices/*/graphics/fb0
$ stat /dev/fb0

I think that's a red herring, isn't it?

That's just the message we get from some bit of gnome-shell (I think it's mutter) on the *initial* attempt to start a Wayland session. We actually expect to see that message any time we hit the fallback mechanism; it's an 'expected failure', more or less. What should happen is we get that message, then gdm should fall back to trying an X11 session instead. At which point the X11 session should start fine, only because of this X "Cannot run in framebuffer mode" error, it doesn't...

d'oh, sorry, no, you're right, that error is coming from X. I was confusing it with a similar GNOME error. My bad.

well i'm wrong for a different reason, this function is apparently supposed to fail for efifb

xorg-x11-drv-vesa-2.4.0-6.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-b65376383f

Yeah, xorg-x11-drv-vesa-2.4.0-6.fc30 fixes the issue. Thanks!

xorg-x11-drv-vesa-2.4.0-6.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-b65376383f

xorg-x11-drv-vesa-2.4.0-6.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.