Bug 1693409 - gdm/X start fails on 'nomodeset' UEFI boot on multiple bare metal systems: "Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices"
Summary: gdm/X start fails on 'nomodeset' UEFI boot on multiple bare metal systems: "C...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-vesa
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Dave Airlie
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Keywords:
Depends On:
Blocks: F30FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2019-03-27 18:52 UTC by Adam Williamson
Modified: 2019-04-25 19:33 UTC (History)
22 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2019-04-25 19:33:49 UTC


Attachments (Terms of Use)
Full journal log from an affected boot (313.97 KB, text/plain)
2019-03-27 18:54 UTC, Adam Williamson
no flags Details
journalctl of failing nvidia 1060 setup (160.17 KB, text/plain)
2019-04-02 06:21 UTC, Julen Landa Alustiza
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
freedesktop.org Gitlab xorg/driver/xf86-video-vesa/merge_requests/1 None None None 2019-04-24 13:51 UTC
Red Hat Bugzilla 1698261 None NEW Failed to start Light Display Manager on the Wandboard Quad (i.MX6) 2019-04-29 15:21 UTC

Internal Trackers: 1698261

Description Adam Williamson 2019-03-27 18:52:55 UTC
Testing 'basic graphics' mode (nomodeset) boot on a UEFI install on my test box with Fedora 30 Beta-1.8, it fails. It does not hit https://bugzilla.redhat.com/show_bug.cgi?id=1691909 or https://bugzilla.redhat.com/show_bug.cgi?id=1683197 , instead, there seems to be an X server error. It tries the 'radeon', 'modesetting' and 'fbdev' drivers and all fail, the errors ending in:

Mar 27 11:47:25 localhost.localdomain /usr/libexec/gdm-x-session[1578]: (EE) Screen 0 deleted because of no matching config section.
Mar 27 11:47:25 localhost.localdomain /usr/libexec/gdm-x-session[1578]: (II) UnloadModule: "radeon"
Mar 27 11:47:25 localhost.localdomain /usr/libexec/gdm-x-session[1578]: (EE) Screen 0 deleted because of no matching config section.
Mar 27 11:47:25 localhost.localdomain /usr/libexec/gdm-x-session[1578]: (II) UnloadModule: "modesetting"
Mar 27 11:47:25 localhost.localdomain /usr/libexec/gdm-x-session[1578]: (EE) Screen 0 deleted because of no matching config section.
Mar 27 11:47:25 localhost.localdomain /usr/libexec/gdm-x-session[1578]: (II) UnloadModule: "fbdev"
Mar 27 11:47:25 localhost.localdomain /usr/libexec/gdm-x-session[1578]: (II) UnloadSubModule: "fbdevhw"
Mar 27 11:47:25 localhost.localdomain /usr/libexec/gdm-x-session[1578]: (EE)
Mar 27 11:47:25 localhost.localdomain /usr/libexec/gdm-x-session[1578]: Fatal server error:
Mar 27 11:47:25 localhost.localdomain /usr/libexec/gdm-x-session[1578]: (EE) Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices

I will attach the full log.

Note this adapter works just fine in 'native' mode, basic graphics is not actually needed on the system - but this could I guess potentially affect hardware of which that is not true?

Comment 1 Adam Williamson 2019-03-27 18:54 UTC
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.

Comment 2 Julen Landa Alustiza 2019-04-02 06:21 UTC
Created attachment 1550886 [details]
journalctl of failing nvidia 1060 setup

Same error on ryzen 5 + nvidia 1060.

Comment 3 Julen Landa Alustiza 2019-04-02 06:23:17 UTC
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

Comment 4 Fedora Blocker Bugs Application 2019-04-08 06:51:16 UTC
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.

Comment 5 Adam Williamson 2019-04-08 15:25:48 UTC
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...

Comment 6 Julen Landa Alustiza 2019-04-08 15:40:58 UTC
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

Comment 7 Adam Williamson 2019-04-08 15:46:56 UTC
"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

Comment 8 Julen Landa Alustiza 2019-04-08 15:50:30 UTC
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

Comment 9 Adam Williamson 2019-04-09 00:40:53 UTC
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.

Comment 10 Chris Murphy 2019-04-09 02:15:03 UTC
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.

Comment 11 František Zatloukal 2019-04-09 07:57:04 UTC
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)

Comment 12 Brian Lane 2019-04-09 23:13:26 UTC
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.

Comment 13 Adam Williamson 2019-04-10 14:59:01 UTC
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).

Comment 14 Lukas Ruzicka 2019-04-10 15:16:50 UTC
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

Comment 15 Adam Williamson 2019-04-10 18:01:56 UTC
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...

Comment 16 Lukas Ruzicka 2019-04-11 11:43:46 UTC
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)

Comment 17 Dominik 'Rathann' Mierzejewski 2019-04-12 09:46:45 UTC
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.

Comment 18 Geoffrey Marr 2019-04-15 20:57:42 UTC
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

Comment 19 Ray Strode [halfline] 2019-04-23 20:30:58 UTC
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

Comment 20 Adam Williamson 2019-04-23 20:33:29 UTC
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...

Comment 21 Adam Williamson 2019-04-23 20:34:49 UTC
d'oh, sorry, no, you're right, that error is coming from X. I was confusing it with a similar GNOME error. My bad.

Comment 22 Ray Strode [halfline] 2019-04-23 20:38:07 UTC
well i'm wrong for a different reason, this function is apparently supposed to fail for efifb

Comment 23 Fedora Update System 2019-04-23 21:44:44 UTC
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

Comment 24 František Zatloukal 2019-04-23 22:15:50 UTC
Yeah, xorg-x11-drv-vesa-2.4.0-6.fc30 fixes the issue. Thanks!

Comment 25 Fedora Update System 2019-04-24 20:27:58 UTC
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

Comment 26 Fedora Update System 2019-04-25 19:33:49 UTC
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.


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