[This is a long description, but here's a summary: X fails under Fedora 19 with VirtualBox. There is already an upstream bug report and proposed fix at <https://bugs.freedesktop.org/show_bug.cgi?id=59825>. I've tested the fix; it *does* fix the problem I'm seeing. Please add that fix to Fedora's build of the X server RPMs.] I am using VirtualBox (v4.2.12) guests running Fedora 19 beta (RC 3.1) with the xorg-x11-server-Xorg-1.14.1-2.fc19 RPM installed. My 32-bit Fedora virtual machine works fine before installing Guest Additions. After Guest Additions are installed, the X server no longer starts correctly. Instead I am simply left with a completely black screen. No mouse pointer or text cursor visible at all. Strangely, my 64-bit Fedora 19 beta (RC 3.1) guest works fine both before and after installing Guest Additions. So whatever is going wrong here seems to be specific to 32-bit environments. Once the guest is in this state, it is not completely frozen. I can ssh into it remotely, it responds properly to ACPI shutdown requests, etc. Just the display is broken. By ssh'ing in remotely after the failure I can observe that no "X" or "Xorg" process is still running. So whatever went wrong, it killed the X server entirely. The last line of "/var/log/Xorg.0.log" reads "(EE) AIGLX error: vboxvideo does not export required DRI extension". But this is probably *not* the fatal problem. I see that same message in the X server log for my working 64-bit guest, followed by several more lines that reveal that the X server is falling back on software rendering: ---------------------------------------------------------------- (EE) AIGLX error: vboxvideo does not export required DRI extension (EE) AIGLX: reverting to software rendering (II) AIGLX: Loaded and initialized swrast (II) GLX: Initialized DRISWRAST GL provider for screen ---------------------------------------------------------------- My 32-bit guest's X server apparently dies after printing just the first of the above output. I've tried ssh'ing in remotely, then launching Xorg within gdb, all as root, to see where the X server is dying. gdb shows the following clues: ---------------------------------------------------------------- ... (initial X server output removed for brevity) ... Initializing built-in extension XFree86-DRI Initializing built-in extension DRIMissing separate debuginfo for /usr/lib/xorg/modules/drivers/vboxvideo_drv.so [tcsetpgrp failed in terminal_inferior: Operation not permitted] Missing separate debuginfo for /usr/lib/dri/vboxvideo_dri.so Missing separate debuginfo for /lib/VBoxOGLcrutil.so Program received signal SIGSEGV, Segmentation fault. _dl_fixup (l=60, reloc_arg=576) at dl-runtime.c:74 74 = (const void *) (D_PTR (l, l_info[DT_JMPREL]) + reloc_offset); ---------------------------------------------------------------- The gdb-reported stack trace at this point of failure is: ---------------------------------------------------------------- #0 _dl_fixup (l=0x9b62e60, reloc_arg=576) at dl-runtime.c:74 #1 0xb7748e70 in _dl_runtime_resolve () at ../sysdeps/i386/dl-trampoline.S:36 #2 0xb6d308b2 in __glXDRIscreenProbe (pScreen=0x9b66948) at glxdri.c:1148 #3 0xb6d274d3 in GlxExtensionInit () at glxext.c:355 #4 0x08107625 in InitExtensions (argc=argc@entry=1, argv=argv@entry=0xbfe03ef4) at ../../../mi/miinitext.c:337 #5 0x080681e0 in main (argc=1, argv=0xbfe03ef4, envp=0xbfe03efc) at main.c:208 ---------------------------------------------------------------- I originally reported this as a VirtualBox bug: <https://www.virtualbox.org/ticket/11821>. A comment there directed me to a similar Arch Linux bug report: <https://bugs.archlinux.org/task/33229>. Reading that, I agree that these are the same issue. The Arch Linux bug report eventually led to an upstream bug report: <https://bugs.freedesktop.org/show_bug.cgi?id=59825>. That report includes a suggested fix. The suggested fix is not already present in the Fedora 19 RPMs. I added that fix to a custom rebuild of the xorg-x11-server-Xorg-1.14.1-4.fc19 RPM. I find that it works: the problem I describe above goes away with this fix added. Can we get that fix added to the official Fedora X server RPMs as well?
Created attachment 758301 [details] suggested fix from upstream This is the suggested fix from upstream <https://bugs.freedesktop.org/show_bug.cgi?id=59825#c1>. I've tested it and I find that it works; the problem I describe vanishes with this fix applied.
I can confirm that this affects F19 beta, on the latest Virtualbox. I installed the guest additions and lost access to the VM, video is all scrambled. However the VM continues working, but is unusable. If I send it a shutdown signal, the VM shuts down. Screenshots: http://img812.imageshack.us/img812/6610/rsmt.png http://img545.imageshack.us/img545/3827/0wp2.png FC
ajax, airlied, can you look at the suggestion from upstream and see if it looks valid? Thanks.
Also saw this on Fedora 19 64 bit, with guest additions installed. I turned off 3d video acceleration in machine configuration and it stopped crashing.
Well , Xorg team this is part of xorg-x11-server , can this be fixed upstream ? and or patch to xorg-x11-server ? --- a/glx/glxdri.c 2013-01-24 22:14:35.216092949 +0100 +++ b/glx/glxdri.c 2013-01-24 22:13:48.499427991 +0100 @@ -971,6 +971,8 @@ __glXDRIscreenProbe(ScreenPtr pScreen) size_t buffer_size; ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen); + framebuffer.base = NULL; +
(In reply to Michael Best from comment #4) > Also saw this on Fedora 19 64 bit, with guest additions installed. I turned > off 3d video acceleration in machine configuration and it stopped crashing. So, and just remove and not load vboxvideo.ko on guest additions ? doesn't also fix the problem on 32 bits guests ? rm /usr/lib/modules/`uname -r`/extra/VirtualBox/vboxvideo.ko rmmod vboxvideo and start X ?
xorg-x11-server-1.14.2-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/xorg-x11-server-1.14.2-3.fc19
Package xorg-x11-server-1.14.2-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xorg-x11-server-1.14.2-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-12681/xorg-x11-server-1.14.2-3.fc19 then log in and leave karma (feedback).
Correction: Update with # su -c 'yum update --enablerepo=updates-testing xorg-x11-server-Xorg-1.14.2-3.fc19'
I like update with yum --advisory=FEDORA-2013-12681 --enablerepo=updates-testing update (as root) and it works ! Now we need upstream this mini patch ASAP Thanks,
Sergio: patch is already upstream as cc3d1a5a6120e721a46c67446ba68f5596055633, I'll get it into the 1.14 branch.
xorg-x11-server-1.14.2-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.