Bug 746509 - black screen in X after installing Fedora-16-TC1-x86_64-Live-Desktop.iso to hard drive
black screen in X after installing Fedora-16-TC1-x86_64-Live-Desktop.iso to h...
Status: CLOSED DUPLICATE of bug 746844
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
Depends On:
Blocks: F16Blocker/F16FinalBlocker
  Show dependency treegraph
Reported: 2011-10-16 14:35 EDT by Andre Robatino
Modified: 2011-10-17 19:01 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-10-17 19:01:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andre Robatino 2011-10-16 14:35:27 EDT
Description of problem:
Fedora-16-TC1-x86_64-Live-Desktop.iso boots successfully and I can install to hard drive and boot into the installed system, but X only has a black screen. I can switch to a VT, however. The problem is specific to x86_64 - Fedora-16-TC1-i686-Live-Desktop.iso works normally.

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

How reproducible:
only tried once

Steps to Reproduce:
1. Boot Fedora-16-TC1-x86_64-Live-Desktop.iso and install to hard drive
2. Reboot into installed system
Actual results:
X has black screen. Don't seem to be able to do anything in it except switch to a VT.

Expected results:
X should work normally.

Additional info:
Both i686 and x86_64 installs are in VirtualBox 4.1.4, using fallback mode in the guest. Assigning to "distribution" since I have no idea what the correct component is.
Comment 1 Zach Carter 2011-10-16 19:25:51 EDT
I reproduced same problem. Applied updates from Virtual screen, it didn't help.
Comment 2 Andre Robatino 2011-10-16 20:03:06 EDT
In bug 746529 the same problem happens except in both i686 and x86_64. I still have my installed i686 and x86_64 guests and in i686 X consistently works properly and in x86_64 it does not, so it will be interesting to see what the difference is.
Comment 3 Petr Schindler 2011-10-17 11:14:21 EDT
I reproduced this too in Virtual Machine Manager 0.8.7. When I try to run firstboot manually it starts and then it stop nearly immediately.
Comment 4 Adam Williamson 2011-10-17 15:46:47 EDT
can we get some X logs, maybe?
Comment 5 Andre Robatino 2011-10-17 16:00:11 EDT
Unfortunately, I just deleted the guests and ISOs to recover space (and would rather not overstress my ailing HDD by reinstalling), but someone else should be able to provide them.
Comment 6 Zach Carter 2011-10-17 16:10:03 EDT
I looked through the X log yesterday and didn't see anything that looked like an error.   I will try to upload the log when I get home tonight, which will not be until after 5PM Pacific time.   Are there any other logs you would like me to grab at the same time?
Comment 7 Zach Carter 2011-10-17 16:11:48 EDT
BTW, I'm using physical hardware, not virtualized like the other two reports in the bug.
Comment 8 Adam Williamson 2011-10-17 17:00:30 EDT
Then you're probably not seeing the same bug.
Comment 9 Zach Carter 2011-10-17 17:06:35 EDT
Ok, the symptom is exactly the same, so I thought it was the same.  I'll file a new bug.
Comment 10 Zach Carter 2011-10-17 17:12:42 EDT
Filed https://bugzilla.redhat.com/show_bug.cgi?id=746827
Comment 11 Adam Williamson 2011-10-17 17:16:52 EDT
well, it's pretty uncertain right now. 'X fails to start with a black screen' is a pretty vague bug. :)
Comment 12 Adam Williamson 2011-10-17 17:53:16 EDT
does seem like lots of people are hitting this, but it's really not at all clear what's going on. i'll see if i can figure anything out. http://forums.fedoraforum.org/showthread.php?t=270932
Comment 13 Adam Williamson 2011-10-17 18:09:54 EDT
I can re-create this in a virt-manager KVM/qemu vm too.

If you do 'systemctl stop firstboot-graphical.service' from the console you'll see X try and start up ten more times or so and fail each time, as prefdm tries to kick in.

If you run 'startx' as root from the console you'll see:

done reset
primary is 0x187ae60
   Zero width or height
new stride: 10240 (display width: 2560, bpp: 4)
   Bad bpp: 1 (1)
   Bad bpp: 1 (1)
   Bad bpp: 1 (1)

then four imsettings errors, which I think are immaterial. Looks like an X issue of some kind. Will have to compare the X logs when booting live.

Those same errors exist in Xorg.0.log, interspersed with other messages. X seems to shut itself down in orderly fashion shortly after the 'Bad bpp' errors.
Comment 14 Adam Williamson 2011-10-17 18:10:53 EDT
hum, if I get a bit more scrollback I see:

"bpp == 8 triggers bugs in spice apparently"

 which seems interesting.
Comment 15 Andre Robatino 2011-10-17 18:21:19 EDT
Do you see it with i686 as well, or just x86_64?
Comment 16 Adam Williamson 2011-10-17 18:21:28 EDT
actually those errors are all there on a successful X run from the live image, which is interesting. I don't think this is in X.

All sorts of stuff seems to be crashing with segfaults in ld-2.14.90.so , if you check /var/log/messages . I think that's the core of the issue. Not sure what's happening to trigger it, though.
Comment 17 Adam Williamson 2011-10-17 18:34:43 EDT
i686 works okay for me.
Comment 18 Adam Williamson 2011-10-17 19:01:16 EDT
I got the crash in firstboot filed via abrt-cli, so closing as a dupe of that bug.

*** This bug has been marked as a duplicate of bug 746844 ***

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