I installed the following packages in Cauldron which is running in a virtual environment using VirtualBox: x11-driver-video-vboxvideo-4.2.10-3.mga3 vboxadditions-kernel-3.8.6-desktop-2.mga3-4.2.10-5.mga3 vboxadditions-kernel-desktop-latest-4.2.10-5.mga3 virtualbox-guest-additions-4.2.10-3.mga3 When /etc/X11/xorg.conf has the following config, Mageia fails to start the GUI: Section "Device" Identifier "device1" VendorName "InnoTek Systemberatung GmbH" BoardName "VirtualBox virtual video card" Driver "vboxvideo" Option "DPMS" EndSection In /var/log/Xorg.0.log, I can read: [ 40.069] (II) LoadModule: "vboxvideo" [ 40.070] (II) Loading /usr/lib/xorg/modules/drivers/vboxvideo_drv.so [ 40.086] (II) Module vboxvideo: vendor="Oracle Corporation" [ 40.086] compiled for 10.13.0, module version = 1.0.1 [ 40.086] Module class: X.Org Video Driver [ 40.086] ABI class: X.Org Video Driver, version 13.1 [ 40.086] (**) Load address of symbol "VBOXVIDEO" is 0xb7054260 [ 40.086] (II) v4l driver for Video4Linux [ 40.086] (II) VBoxVideo: guest driver for VirtualBox: vbox [ 40.086] (++) using VT number 1 [ 40.101] (WW) Falling back to old probe method for v4l [ 40.102] (II) VBoxVideo(0): VirtualBox guest additions video driver version 4.2.10_OSE which seems to indicate that vboxvideo is loaded, but the last line of the log file is: [ 41.157] (EE) AIGLX error: vboxvideo does not export required DRI extension which seems to indicate that it couldn't be loaded correctly. What I get is a black screen, and I have to restart Cauldron using the installation CD to use the rescue console to access xorg.conf and replace vboxvideo by vesa to have a chance to start the GUI again.
i confirm this bug, i have exactly the same behaviour after the last upgrade of the virtualbox-guest-additions on the guest OS (mageia 3B4).
CC: (none) => mnaud.free
Maybe the new VirtualBox 4.2.12 (release 2013-04-12) will fix the problem. https://www.virtualbox.org/wiki/Changelog I just completed the VirtualBox-4.2.12-84980-Linux_amd64.run host and guest and did not have any problems. $ uname -r 3.8.6-desktop-2.mga3 $ cat /etc/release Mageia release 3 (Cauldron) for x86_64
Source RPM: (none) => virtualbox
Yep, I think so. I've pushed 4.2.12 to buildsystem now so it soon be on mirrors
CC: (none) => tmb
kernel 3.8.7 + virtualbox 4.2.12. Same problem, same errors in log files. The screen remains black. No way to log in.
Created attachment 3745 [details] Xorg log before black screen I've had this bug after update vbox video driver to 4.2.12, here is how I tried to produce this log: 1.boot in failsafe mode (log into console) 2.run drakx11 -- make sure vbox video driver is used 3.click [TEST] Get black screen and hangs
CC: (none) => yochenhsieh
Attachment 3745 mime type: application/octet-stream => text/plain
According to various posts, "vboxvideo does not export required DRI" is just a warning, not the root issue here.
CC: (none) => thierry.vignaud
*** Bug 9759 has been marked as a duplicate of this bug. ***
CC: (none) => luigiwalser
*** Bug 9807 has been marked as a duplicate of this bug. ***
CC: (none) => jan
Assignee: bugsquad => tmbPriority: Normal => release_blocker
Whiteboard: (none) => 3RCCC: (none) => davidwhodgins, eeeemail, ennael1
There's a lot more information in Bug 9759. As Milan points out there, x11-server could be the real culprit. I tried rebuilding the kernel and virtualbox RPMs from back when this was working fine when I tested right before the mass rebuild in January. I rebuilt the kernel 3.7.1 from revision 332447 and virtualbox 4.2.6 from revision 388924, from December and January respectively. That did not fix the problem, nor did it fix the problems in X with the mouse wheel working and the Automatic resolution not working (likely related to Bug 8810). The only strange thing is that all of the current packages work with the Mageia 2 kernel (2.4.34 from updates), although the Automatic resolution and mouse wheel issues are still present.
CC: (none) => darreljohnston, makowski.mageia, minkob
Please try with virtualbox-4.2.12-2.mga3
Still same black screen here with virtualbox-4.2.12-2.mga3.
I built the updated virtualbox 4.2.12-2.mga3 from SVN. Side note to Thomas: *please* make that gsoap webservice thing a build-time option in the SPEC. virtualbox takes a lot longer to build with that thing, and compiling those soap files made my VM unresponsive for minutes at a time. Anyway, the updated virtualbox package does not fix anything. However, I have verified Milan's suspicion that x11-server is the culprit. I built x11-server 1.13.1.901 (aka 1.13.2 RC1) from SVN revision 338950 and x11-server 1.13.2 from revision 397217, and those both work fine (including Automatic resolution and mouse wheel working) with both the current virtualbox package as well as 4.2.6.
Source RPM: virtualbox => x11-server
Based on when people seemed to start having problems and looking at the SVN log of x11-server, I got a hunch that the problem may have been caused by the patch (100) added in SVN revision 409375 on April 10th and built the current x11-server package without that patch. Everything works! X works with the current virtualbox, the mouse wheel works, and Automatic resolution works.
Thomas, I think you should revert that patch since it's useless anyway (it didn't fix the sis driver)
Yep, patch dropped in x11-server-1.13.4-2.mga3 Thanks David for tracking it down.
Please reopen if it still happen with latest x11-server
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
https://bugs.mageia.org/show_bug.cgi?id=9759 After today's update of x11-server and virtualbox packages, all issues have been resolved. It wasn't as easy as just updating and rebooting. I had to uninstall all dkms and virtualbox packages and remove xorg.conf. After doing so and rebooting, I reinstalled virtualbox guest additions, then rebooted. Everything is now working normally again. Thanks, gentlemen.
it happens again on Cauldron 4 (a new cauldron install on the guest; virtualbox-4.2.12-2.mga3 on the host) I had to remove the kernel module vboxvideo (fromdkms-vboxadditions-4.2.12-5.mga4) for X11 to work on the guest (of course, no DRI, but at least it works)
CC: (none) => pabloResolution: FIXED => (none)Status: RESOLVED => REOPENED
Then it's a different, if perhaps similar, issue. Please open a new bug.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
ok, created bug #10442 for the new (Cauldron 4) one
CC: (none) => doktor5000