Bug 1628495 - In UEFI mode, Fedora 29 cannot be installed in Safe Graphics Mode
Summary: In UEFI mode, Fedora 29 cannot be installed in Safe Graphics Mode
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 29
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker https://fedoraproject...
Keywords: CommonBugs
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-09-13 08:50 UTC by Lukas Ruzicka
Modified: 2019-01-28 16:25 UTC (History)
23 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)
Journalctl for the UEFI installation (327.10 KB, text/plain)
2018-09-13 08:50 UTC, Lukas Ruzicka
no flags Details
X.log for the UEFI installation (13.95 KB, text/plain)
2018-09-13 08:51 UTC, Lukas Ruzicka
no flags Details
Journalctl for the BIOS installation (553.65 KB, text/plain)
2018-09-13 08:52 UTC, Lukas Ruzicka
no flags Details
X.log for the BIOS installation (75.54 KB, text/plain)
2018-09-13 08:52 UTC, Lukas Ruzicka
no flags Details
journalctl, with drm.debug=0xe nomodeset set (214.33 KB, text/plain)
2018-09-15 00:41 UTC, Chris Murphy
no flags Details
journal, xorg-x11-server-1.20.1-3.fc29.jx1 applied (204.22 KB, text/plain)
2018-09-17 19:10 UTC, Chris Murphy
no flags Details
Xorg log (22.40 KB, text/plain)
2018-09-17 22:49 UTC, Chris Murphy
no flags Details
journal full, nomodeset enforcing=0 (192.72 KB, text/plain)
2018-09-18 18:16 UTC, Chris Murphy
no flags Details
hp spectre journal 20181019 (212.48 KB, text/plain)
2018-10-19 17:09 UTC, Chris Murphy
no flags Details
X.log from UEFI minimal graphics mode (nomodeset) (7.26 KB, text/plain)
2018-12-03 19:18 UTC, Julian Sikorski
no flags Details
X.log from BIOS normal mode for comparison (58.54 KB, text/plain)
2018-12-03 19:26 UTC, Julian Sikorski
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1629860 None NEW Fedora 29 Live ISO does not work in safe mode due to "Failed to create backend: Could not find a primary drm kms device" 2019-04-04 12:12 UTC

Internal Trackers: 1629860

Description Lukas Ruzicka 2018-09-13 08:50:43 UTC
Created attachment 1482959 [details]
Journalctl for the UEFI installation

Description of problem:

On my testing machine, in UEFI mode, Fedora 29 cannot be installed using the Safe Graphics Mode. Anaconda suggests to fallback to text mode or installing over VNC.
In BIOS mode, everything is fine.

Version-Release number of selected component (if applicable):

Fedora 29 Beta RC 1.1

How reproducible:

Always

Steps to Reproduce:
1. Boot from USB, choose Troubleshooting and Installation via Safe Mode
2. Wait for it.

Actual results:

Installation can only proceed in text mode or VNC.

Expected results:

Safe graphics mode should work.

Additional info:

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

See logs attached.

Comment 1 Lukas Ruzicka 2018-09-13 08:51 UTC
Created attachment 1482960 [details]
X.log for the UEFI installation

Comment 2 Lukas Ruzicka 2018-09-13 08:52 UTC
Created attachment 1482961 [details]
Journalctl for the BIOS installation

Comment 3 Lukas Ruzicka 2018-09-13 08:52 UTC
Created attachment 1482962 [details]
X.log for the BIOS installation

Comment 4 Chris Murphy 2018-09-14 23:01:15 UTC
I'm seeing this also with i915 graphics.

[   11.887615] localhost kernel: [drm:i915_init [i915]] KMS disabled.
...
[   20.839818] localhost kernel: Lockdown: Xorg: ioperm is restricted; see man kernel_lockdown.7
...
[   20.095996] localhost gnome-shell[1502]: Failed to create backend: Could not find a primary drm kms device

Comment 5 Fedora Blocker Bugs Application 2018-09-14 23:13:23 UTC
Proposed as a Blocker for 29-beta by Fedora user chrismurphy 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.

Comment 6 Adam Williamson 2018-09-14 23:27:18 UTC
To confirm, does F28 work OK in the same test on the same systems? Thanks!

Comment 7 Adam Williamson 2018-09-15 00:16:13 UTC
I confirm this on my laptop (XPS 13 Kaby Lake), and indeed F28 *does* work. It seems that on F28, fbdev works - I see many logs from FBDEV, including stuff like setting the DPI (indicating it's really doing the work).

Comment 8 Adam Williamson 2018-09-15 00:22:18 UTC
Note, on my system I don't see Chris' ioperm message, or the "xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)" message from Lukas' X log. But I still get the same error in the end:

(EE) Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices

Comment 9 Chris Murphy 2018-09-15 00:41 UTC
Created attachment 1483419 [details]
journalctl, with drm.debug=0xe nomodeset set

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]

Comment 10 Adam Williamson 2018-09-15 02:03:30 UTC
Mine's:

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 620 [8086:5916] (rev 02)

Comment 11 Chris Murphy 2018-09-15 16:39:36 UTC
I don't think this is a kernel bug. Same kernel+initramfs combo pointed to an f28 rootfs, and with nomodeset I do get to a usable GDM and can login graphically.

Comment 12 Adam Williamson 2018-09-15 16:53:54 UTC
ajax thinks it's in X server autodetect.

Comment 13 Chris Murphy 2018-09-15 17:42:40 UTC
Slightly off topic but I also see this:

Sep 15 10:55:21 f29h.local systemd[1351]: Started Mark boot as successful after the user session has run 2 minutes.

And now I get to ask elsewhere what the definition of successful is...

Comment 14 Adam Jackson 2018-09-17 17:20:30 UTC
If someone who can repro this can try this build, that'd be great:

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

This changes the logic for the no-config-file case to not attempt to load the vesa driver on UEFI machines, as it's pretty much not going to work. Hoepefully with this in place the fbdev driver will be used as expected.

Note that if the difficulty in testing this is getting the scratch build into the install image: don't bother. Instead, install in text mode, make sure 'nomodeset' is on the kernel command line; try to run X and verify that you get the same failure; then install the new build and try again.

Comment 15 Chris Murphy 2018-09-17 19:10 UTC
Created attachment 1484124 [details]
journal, xorg-x11-server-1.20.1-3.fc29.jx1 applied

I've upgraded to xorg-x11-server-1.20.1-3.fc29.jx1 with a Fedora 29 system (installed, not installer media), and I get the same problem, no X.

Comment 16 Geoffrey Marr 2018-09-17 20:02:03 UTC
Discussed during the 2018-09-17 blocker review meeting: [1]

The decision to delay the classification of this as a blocker bug was made as we have information that leads us to believe that this may only affect hardware that works fine with a native driver, and if that is the case, this would not qualify as a blocker. We will get with ajax and vote again at the next meeting.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-09-17/f29-blocker-review.2018-09-17-16.02.txt

Comment 17 Adam Jackson 2018-09-17 22:02:43 UTC
(In reply to Chris Murphy from comment #15)
> Created attachment 1484124 [details]
> journal, xorg-x11-server-1.20.1-3.fc29.jx1 applied
> 
> I've upgraded to xorg-x11-server-1.20.1-3.fc29.jx1 with a Fedora 29 system
> (installed, not installer media), and I get the same problem, no X.

That journal doesn't seem to show the X server ever being launched. It looks to start to blow up around here:

[    6.987540] f29h.local gnome-shell[930]: Failed to create backend: Could not find a primary drm kms device

Can you try launching X from the command line? You'll need to be root, and the log file (/var/log/Xorg.0.log, not going to be in the journal) from "X -retro -pogo" should be sufficient to see what's going on.

Comment 18 Chris Murphy 2018-09-17 22:49 UTC
Created attachment 1484209 [details]
Xorg log

# X -retro -pogo

X.Org X Server 1.20.1
X Protocol Version 11, Revision 0
Build Operating System:  4.17.3-200.fc28.x86_64 
Current Operating System: Linux f29h.local 4.18.7-300.fc29.x86_64 #1 SMP Mon Sep 10 15:37:17 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/root29/boot/vmlinuz-4.18.7-300.fc29.x86_64 root=UUID=2662057f-e6c7-47fa-8af9-ad933a22f6ec ro rootflags=subvol=root29 enable_mtrr_cleanup=1 zswap.enabled=1 zswap.max_pool_percent=25 zswap.compressor=lz4 drm.debug=0x1e nomodeset 3
Build Date: 17 September 2018  05:18:57PM
Build ID: xorg-x11-server 1.20.1-3.fc29.jx1 
Current version of pixman: 0.34.0
        Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Sep 17 16:37:21 2018
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Unsupported high keycode 372 for name <1372> ignored
                    X11 cannot support keycodes above 255.
                    This warning only shows for the first high keycode.
Errors from xkbcomp are not fatal to the X server
(II) Server terminated successfully (0). Closing log file.
#

Comment 19 Adam Jackson 2018-09-18 16:15:41 UTC
(In reply to Chris Murphy from comment #18)
> Created attachment 1484209 [details]
> Xorg log

That looks like success to me:

[   117.810] (II) FBDEV(0): hardware: EFI VGA (video memory: 8100kB)
[   117.810] (DB) xf86MergeOutputClassOptions unsupported bus type 0
[   117.810] (II) FBDEV(0): checking modes against framebuffer device...
[   117.810] (II) FBDEV(0): checking modes against monitor...
[   117.810] (II) FBDEV(0): Virtual size is 1920x1080 (pitch 1920)
[   117.810] (**) FBDEV(0):  Built-in mode "current": 207.4 MHz, 85.3 kHz, 77.2 Hz
[   117.810] (II) FBDEV(0): Modeline "current"x0.0  207.38  1920 1952 2192 2432  1080 1084 1088 1104 -hsync -vsync -csync (85.3 kHz b)
[   117.810] (==) FBDEV(0): DPI set to (96, 96)

And then, as stderr notes:

> (II) Server terminated successfully (0). Closing log file.

So the X server change seems like a fine plan, but I'm unclear why it wouldn't be sufficient.

Comment 20 Adam Jackson 2018-09-18 16:47:12 UTC
halfline suggests it might have something to do with:

[    6.758929] f29h.local systemd[851]: selinux: avc:  denied  { status } for auid=n/a uid=42 gid=42 cmdline="/usr/libexec/gdm-wayland-session gnome-session --autostart /usr/share/gdm/greeter/autostart" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=system permissive=0
[    6.793867] f29h.local systemd[851]: selinux: avc:  denied  { reload } for auid=n/a uid=42 gid=42 cmdline="/usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=system permissive=0
[    6.795764] f29h.local systemd[851]: selinux: avc:  denied  { reload } for auid=n/a uid=42 gid=42 cmdline="/usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=system permissive=0
[    6.797368] f29h.local systemd[851]: selinux: avc:  denied  { reload } for auid=n/a uid=42 gid=42 cmdline="/usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=system permissive=0
[    6.798749] f29h.local systemd[851]: selinux: avc:  denied  { reload } for auid=n/a uid=42 gid=42 cmdline="/usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=system permissive=0
[    6.812389] f29h.local systemd[851]: selinux: avc:  denied  { reload } for auid=n/a uid=42 gid=42 cmdline="/usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=system permissive=0

Do things work if you boot with enforcing=0 ?

Comment 21 Chris Murphy 2018-09-18 18:16 UTC
Created attachment 1484461 [details]
journal full, nomodeset enforcing=0

Still no graphical environment.

Comment 22 Chris Murphy 2018-09-18 18:32:10 UTC
And with selinux=0 it still fails.

Comment 23 Adam Williamson 2018-09-19 22:58:28 UTC
I actually did build an installer image with the scratch build, and for me it works. A Beta RC4 image does not reach the installer GUI on my test box booted UEFI with 'basic graphics', the test image with the scratch build does.

I suspect Chris' problems may be partly to do with GNOME; the installer doesn't run GNOME, just X and a wm.

Comment 24 Adam Williamson 2018-09-20 23:14:52 UTC
Discussed at 2018-09-20 Fedora 29 Beta Go/No-Go meeting, acting as a blocker review meeting. Rejected as a blocker, as this seems limited in scope and has not yet been shown to affect any system that actually needs basic graphics mode (all affected systems so far boot fine in 'normal' mode). I'd also note that technically the criterion covers the presence and behaviour of *the boot menu item*, not the actual success or failure of the boot once the boot menu item did the right thing.

Comment 25 Dave Young 2018-10-19 14:02:20 UTC
It looks like you are using a radeon graphic card but it only support kms mode so it is expected that basic mode can not work:

Sep 13 08:32:41 localhost kernel: [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module!

Are you testing i915 along with radeon?   Maybe you can remove the radeon card and test i915 only if possible.

Comment 26 Chris Murphy 2018-10-19 17:09 UTC
Created attachment 1495713 [details]
hp spectre journal 20181019

I'm still having the problem on an HP Spectre which only has i915 graphics; and it boots with nomodeset fine under Fedora 28. Attaching journal for today's attempt.

Comment 27 Julian Sikorski 2018-12-03 19:18 UTC
Created attachment 1511076 [details]
X.log from UEFI minimal graphics mode (nomodeset)

I believe I might be having a similar issue: I am trying to install Fedora on a newly built machine with Nvidia RTX 2070 GPU. In BIOS mode, X starts using what seems like vesa driver, but in UEFI mode X does not start due to:

(EE) Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices

The non-minimal mode does not work either.

Comment 28 Julian Sikorski 2018-12-03 19:26 UTC
Created attachment 1511077 [details]
X.log from BIOS normal mode for comparison

Comment 29 Willan Rampazzo 2018-12-13 23:33:15 UTC
I can confirm the problem stated by comment 27 using normal mode. Even if I set machine bios to use Intel Graphics instead of PCIe, Fedora won't start X.

Comment 30 Mic 2018-12-20 12:00:45 UTC
Exactly the same issue as comments 27 & 29 with GeForce NVIDIA RTX 2070.

I don't know how to proceed with the install in this situation. How can I launch the install process?

I would gladly do it in text mode and then install NVIDIA driver later, but I understand partitions & LVM/encryption stuff cannot be setup in text-mode.

Comment 31 Julian Sikorski 2018-12-20 12:05:43 UTC
(In reply to Mic from comment #30)
> Exactly the same issue as comments 27 & 29 with GeForce NVIDIA RTX 2070.
> 
> I don't know how to proceed with the install in this situation. How can I
> launch the install process?
> 
> I would gladly do it in text mode and then install NVIDIA driver later, but
> I understand partitions & LVM/encryption stuff cannot be setup in text-mode.

If you connect the machine with RTX 2070 via a wired network and have another device on which you can install a vnc client, you can install using vnc. It worked for me at least.
https://docs.fedoraproject.org/en-US/fedora/f29/install-guide/advanced/VNC_Installations/

Comment 32 Mic 2018-12-20 16:13:09 UTC
Yeah cool, thanks, that worked well.
And then followed the NVIDIA installation steps from: https://www.if-not-true-then-false.com/2015/fedora-nvidia-guide/#before-installation

Comment 33 Shabang 2019-01-22 14:24:10 UTC
Similar problem on a Huawei 1288H V5 server

Resolved adding the anaconda option 'usefbx' at boot

#!

Comment 34 Chad 2019-01-28 16:25:13 UTC
Same issue with a SuperMicro X11SSH-LN4F; confirmed that adding "inst.usefbx" resolves the problem.


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