Description of problem:
Xserver does not start in virtualbox.
The running time was Fedora16
Version-Release number of selected component (if applicable):
VirtualBox-4.1.8 on Win7-x64
With no working of X, to start X
Steps to Reproduce:
1. run X
2. X fails to start...
See Attachment log
Fatal server error:
[ 42.502] no screens found
start X server
Created attachment 558283 [details]
[ 42.499] (II) VESA(0): Primary V_BIOS segment is: 0xc000
[ 42.502] (II) VESA(0): VESA BIOS not detected
***********That is EXACTLY what I am encountering with when starting Xorg within VBox, as is described in BZ#783995.
The RATS images, and 17 Alpha TC1, have the same problem with VirtualBox. When using a KVM guest and choosing basic graphics mode (vesa) from the boot menu, X starts but the graphics are totally corrupted, so it may be the same problem. Problem exists with both i386 and x86_64 images. My VirtualBox 4.1.8 Rawhide guest has not had working X in months.
Proposing as F17 Alpha Blocker. Note that the problem exists even with KVM (when using the vesa driver in basic graphics mode).
From https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria :
The boot menu for all installation 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 and attempting to use the generic driver
Well, that criterion is meant to ensure that the boot menu entry exists and does the right thing, which it does. Bugs in the vesa driver itself are not necessarily blocker material; we don't strictly require VirtualBox to work OOTB, and KVM does not use vesa by default but cirrus or qxl. I'd lean towards -1 blocker on this, but we still ought to fix it.
Fedora Bugzappers volunteer triage team
*** Bug 783995 has been marked as a duplicate of this bug. ***
Try the fix in https://lists.fedoraproject.org/pipermail/test/2012-February/105476.html . It works for me.
Created attachment 560417 [details]
screenshot of working vesa driver
Yes! libpciaccess-0.12.902-4.fc17 (http://koji.fedoraproject.org/koji/buildinfo?buildID=298151) well works for me with Gnome Shell software rendering automatically turned on.
Closing since this appears fixed, OP please reopen if it does not work for you now.