Bug 785652
| Summary: | Xserver does not start in virtualbox | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | YohsukećOoi <001> | ||||||
| Component: | xorg-x11-drv-vesa | Assignee: | X/OpenGL Maintenance List <xgl-maint> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | rawhide | CC: | awilliam, bigslowfat, robatino, satellitgo, xgl-maint | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2012-02-09 17:53:17 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 752648 | ||||||||
| Attachments: |
|
||||||||
|
Description
Yohsuke Ooi
2012-01-30 07:31:18 UTC
Created attachment 558283 [details]
Xorg.0.log
[ 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 https://fedoraproject.org/wiki/BugZappers *** 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. |