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.
Created attachment 1482960 [details] X.log for the UEFI installation
Created attachment 1482961 [details] Journalctl for the BIOS installation
Created attachment 1482962 [details] X.log for the BIOS installation
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
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.
To confirm, does F28 work OK in the same test on the same systems? Thanks!
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).
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
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]
Mine's: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 620 [8086:5916] (rev 02)
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.
ajax thinks it's in X server autodetect.
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...
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.
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.
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
(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.
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. #
(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.
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 ?
Created attachment 1484461 [details] journal full, nomodeset enforcing=0 Still no graphical environment.
And with selinux=0 it still fails.
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.
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.
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.
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.
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.
Created attachment 1511077 [details] X.log from BIOS normal mode for comparison
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.
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.
(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/
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
Similar problem on a Huawei 1288H V5 server Resolved adding the anaconda option 'usefbx' at boot #!
Same issue with a SuperMicro X11SSH-LN4F; confirmed that adding "inst.usefbx" resolves the problem.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.