Bug 746509 - black screen in X after installing Fedora-16-TC1-x86_64-Live-Desktop.iso to hard drive
Summary: black screen in X after installing Fedora-16-TC1-x86_64-Live-Desktop.iso to h...
Keywords:
Status: CLOSED DUPLICATE of bug 746844
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 16
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F16Blocker, F16FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2011-10-16 18:35 UTC by Andre Robatino
Modified: 2011-10-17 23:01 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-10-17 23:01:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Andre Robatino 2011-10-16 18:35:27 UTC
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):
Fedora-16-TC1-x86_64-Live-Desktop.iso

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 23:25:51 UTC
I reproduced same problem. Applied updates from Virtual screen, it didn't help.

Comment 2 Andre Robatino 2011-10-17 00:03:06 UTC
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 15:14:21 UTC
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 19:46:47 UTC
can we get some X logs, maybe?

Comment 5 Andre Robatino 2011-10-17 20:00:11 UTC
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 20:10:03 UTC
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 20:11:48 UTC
BTW, I'm using physical hardware, not virtualized like the other two reports in the bug.

Comment 8 Adam Williamson 2011-10-17 21:00:30 UTC
Then you're probably not seeing the same bug.

Comment 9 Zach Carter 2011-10-17 21:06:35 UTC
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 21:12:42 UTC
Filed https://bugzilla.redhat.com/show_bug.cgi?id=746827

Comment 11 Adam Williamson 2011-10-17 21:16:52 UTC
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 21:53:16 UTC
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 22:09:54 UTC
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 22:10:53 UTC
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 22:21:19 UTC
Do you see it with i686 as well, or just x86_64?

Comment 16 Adam Williamson 2011-10-17 22:21:28 UTC
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 22:34:43 UTC
i686 works okay for me.

Comment 18 Adam Williamson 2011-10-17 23:01:16 UTC
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.