Bug 785652 - Xserver does not start in virtualbox
Summary: Xserver does not start in virtualbox
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-vesa
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
: 783995 (view as bug list)
Depends On:
Blocks: F17Alpha, F17AlphaBlocker
TreeView+ depends on / blocked
Reported: 2012-01-30 07:31 UTC by Yohsuke Ooi
Modified: 2012-02-09 17:53 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-02-09 17:53:17 UTC
Type: ---

Attachments (Terms of Use)
Xorg.0.log (7.65 KB, application/octet-stream)
2012-01-30 07:40 UTC, Yohsuke Ooi
no flags Details
screenshot of working vesa driver (78.83 KB, image/jpeg)
2012-02-09 01:09 UTC, bsfmig
no flags Details

Description Yohsuke Ooi 2012-01-30 07:31:18 UTC
Description of problem:

Xserver does not start in virtualbox.
The running time was Fedora16

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


running enviroment

VirtualBox-4.1.8 on Win7-x64

How reproducible:

With no working of X, to start X

Steps to Reproduce:
1. run X
2. X fails to start...
   See Attachment log
Actual results:

Fatal server error:
[    42.502] no screens found

Expected results:

start X server

Additional info:

Comment 1 Yohsuke Ooi 2012-01-30 07:40:42 UTC
Created attachment 558283 [details]

Comment 2 bsfmig 2012-02-03 14:58:00 UTC
[    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.

Comment 3 Andre Robatino 2012-02-03 18:51:48 UTC
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.

Comment 4 Andre Robatino 2012-02-03 18:54:49 UTC
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

Comment 5 Adam Williamson 2012-02-03 19:14:51 UTC
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

Comment 6 bsfmig 2012-02-05 05:34:55 UTC
*** Bug 783995 has been marked as a duplicate of this bug. ***

Comment 7 Andre Robatino 2012-02-08 21:38:19 UTC
Try the fix in https://lists.fedoraproject.org/pipermail/test/2012-February/105476.html . It works for me.

Comment 8 bsfmig 2012-02-09 01:09:19 UTC
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.

Comment 9 Andre Robatino 2012-02-09 17:53:17 UTC
Closing since this appears fixed, OP please reopen if it does not work for you now.

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