Description of problem: I've created a LiveUSB with Fedora-18-Beta-x86_64-Live-KDE.iso, dated 20 Nov 2012. The Live USB works fine on a non-UEFI system -- I am able to surf the web from the USB OS. When the Live USB is used to boot a UEFI system, the system displays a "Secure Boot Disabled" message, then the boot cycle proceeds normally. The system enters runlevel 5 and displays the KDE splash screen as KDE begins to load. Before the splash screen has finished rendering it's fuzzy objects in focus, the screen goes blank. Music is played through the speakers as a mouse cursor appears on the blank screen. It's not possible to exit the GUI to text mode -- Ctrl-Alt-Backspace does nothing. With a blank display, it's not possible to glean any useful information from the system to help ID the problem. Version-Release number of selected component (if applicable): Fedora-18-Beta-x86_64-Live-KDE.iso, dated 20 Nov 2012 How reproducible: Every time. Steps to Reproduce: 1. Use liveusb-creator to create Live USB using Fedora-18-Beta-x86_64-Live-KDE.iso, dated 20 Nov 2012 2. Boot Live USB on a non-UEFI system to verify functionality 3. Boot Live USB on a UEFI system & observe blank screen in KDE GUI Actual results: Live USB boots and loads KDE, but the GUI environment produces a blank (black) screen with a functional/visible mouse cursor and sound. Expected results: Functional KDE desktop. Additional info:
Created attachment 661013 [details] cups access_log
Created attachment 661014 [details] spice-vdagent.log
Created attachment 661015 [details] Xorg.0.log
Created attachment 661016 [details] wtmp
Created attachment 661017 [details] lastlog
Created attachment 661018 [details] messages
Created attachment 661021 [details] secure
To try to get better insights into what's going on, I've done the following: 1. I booted to runlevel 3 by editing grub2's kernel command line during boot. 2. I installed the package net-tools 3. I obtained the IP address of the PC using ifconfig 4. I started the SSH daemon 5. I changed the root password 6. I SSH'd into the box from another PC 7. I ran "startx" locally and watched the box lock-up the keyboard with a blank screen after KDE loaded. the mouse still worked. 8. I used SSH to download the contents of /var/log that had timestamps after X was started. I hope this helps.
seems like some sort of video driver glitch, but my perusing doesn't show anything very helpful. Maybe try logging in to KDE Plasma Workspace (failsafe session) instead? (this should disable any attempt to use compositing/desktop effects). though doing so may be difficult due to live's autologin triaging to xorg-x11-drv-nouveau for now.
I just tried performing a yum update in runlevel 3 to get the latest RPM, hoping that the updated xorg files & video drivers would be helpful. unfortunately the update failed when the 3 GB root file system on the live USB ran out of space. :( I could boot into runlevel 3 by altering the kernel command line in grub, but I'm not sure how to force KDE into a failsafe session. If you could advise on how to do that, I could create a new live USB and give it a try. Alternatively, is there a way to increase the size of the / filesystem? I created a 4 GB overlay when making the live USB but that doesn't seem to have helped. I'm thinking it would be helpful to be able to run a live USB with the most current package updates. Thanks.
I've had ongoing failures with every GUI based install, but I've managed to perform a netinstall via VNC to get F18 installed onto bare metal. I have a working text mode system now that should make this problem easier to diagnose. I continue to have the same problem with the bare-metal installation that I had with the Live media: When X11 loads the GUI I get the splash screen, but it progresses to a blank screen display (black screen) with a working mouse cursor. Probably related to the video driver. Here's some additional debugging information: # lspci | grep 'VGA' 01:00.0 VGA compatible controller: NVIDIA Corporation NV37GL [Quadro FX 330/GeForce PCX 5300] (rev a2) Dmesg attachment and Xorg.0.log to follow.
Created attachment 661960 [details] dmesg output
Created attachment 661961 [details] Xorg.0.log
Based upon post-installation testing on a new bare metal installation, it appears that this problem is caused by the nouveau driver not supporting "older" PCIExpress video cards by nvidia. Once F18 is installed on a box using the aforementioned video system, it has the same problem with blank screens as X11 enters the high resolution GUI mode. Replacing the nouveau driver with the proprietary nvidia driver eliminates the problem. I'm wondering if this problem with the installation media may be attributable to the use of the nouveau driver and it's lack of support for some PCIE nvidia boards. Additional information in Bug 886638. Hope this helps.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 'version' of '18'. 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 prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 to Fedora 18's end of life. 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 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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.