In a fresh install of Cauldron 4 on a virtualbox guest (virtualbox-4.2.12-2.mga3 on the host) X11 fails to launch. I had to remove the kernel module vboxvideo (from dkms-vboxadditions-4.2.12-5.mga4) for X11 to work on the guest (of course, no DRI, but at least it works) Possible culprits: x11-server, dkms-vboxadditions (the vboxvideo kernel module on the guest), x11-driver-video-vboxvideo (the X11 driver used on the guest). The same host settng worked when Mageia3 was installed on the guest (but maybe vboxvideo kernel module wasn't used? It *seems* that downgrading the x11-* and dkms-vboxadditions-* packages to those of mga3 the kernel module is not automatically loaded; while it is always loaded with the mga4 packages, even if I unselect all options on XFdrake config) see also maybe related old bug #9716 Reproducible: Steps to Reproduce:
It looks like there's an issue between virtualbox and x11-server 1.14 though 4.2.12 is supposed to handle it. Can you attach your guest's /var/log/Xorg.0.log (with vboxvideo)?
Keywords: (none) => NEEDINFOCC: (none) => thierry.vignaudSource RPM: x11-server => virtualbox
Created attachment 4113 [details] Xorg.4.log the only error is "(EE) AIGLX error: vboxvideo does not export required DRI extension" (exactly like in the old bug #9716). could it be that the change to x11-server 1.14 introduced the same problem as in the patch number 100 of x11-server-1.13.4-2.mga3 ? here is the complete log anyway
CC: (none) => pablo
CC: (none) => wilcal.int
I'm experiancing a Vbox freeze during an install of M3. Seems to be at random points after install and when adding apps. At some point the Vbox guest freezes and the only way out is to ctrl-alt-f2 the system, get to root terminal then reboot the system. Looks like an X11 thing as the screen kinda goes grey when it does this. More testing on my part.
I can confirm this problem using Mageia 3 Release. On a virtualbox guest (Virtualbox 4.2.18 Windows 7 Pro on the host) X11 fails to launch. When kernel module vboxvideo is loaded at system start i get the same error as mentioned in Comment 2. Without the kernel module X11 works but without DRI. RPMS installed: dkms-vboxadditions-4.2.16-1.mga3.noarch.rpm vboxadditions-kernel-desktop-latest-4.2.16-1.mga3.i586.rpm x11-driver-video-vboxvideo-4.2.16.-1mga3.i586.rpm x11-server-xorg-1.13.4-2.mga3.i586.rpm I can provide the full logfile as well on request.
CC: (none) => s.puch
I get this problem as well with the same package versions as Stefan. I was able to manually modprobe vboxvideo then log out and log back in. The driver then works in the sense that DRI is enabled and GUI performance is much improved, but another issue creeps up in the form of the wallpaper appearing totally corrupted. Is this graphical corruption related to why the driver isn't being automatically loaded at boot?
CC: (none) => philippe.l
CC: (none) => doktor5000
Wow, this is a super old cauldron bug (no action since almost 2 years ago!) Is it still valid for current cauldron and/or Mga5?
CC: (none) => marja11
OK, from my point of view the bug in MGA5 changed a little bit. X11 does not crash anymore on start of Xsession but vboxvideo still does not provide DRI support. Kernel module vboxvideo is loaded at system start but the error as mentioned in Comment 2 is still existing. [ 11.519] (EE) AIGLX error: vboxvideo does not export required DRI extension [ 11.519] (EE) AIGLX: reverting to software rendering RPMS installed: vboxadditions-kernel-4.1.12-desktop-1.mga5-5.0.8-2.mga5.i586.rpm vboxadditions-kernel-desktop-latest-5.0.8-2.mga5.i586.rpm x11-driver-video-vboxvideo-5.0.8-1.mga5.i586.rpm x11-server-xorg-1.16.4-2.1.mga5.i586.rpm I will attach the full output from Xorg.0.log
Created attachment 7204 [details] Logfile from xorg on mga5 x86
Some additional infos that may be helpful: I replaced vboxadditions-kernel-4.1.12-desktop-1.mga5-5.0.8-2.mga5.i586.rpm vboxadditions-kernel-desktop-latest-5.0.8-2.mga5.i586.rpm with dkms-vboxadditions-5.0.8-1.mga5 dkms-virtualbox-5.0.8-1.mga5 dkms-2.0.19-34.mga5 which builds the modules during installation. The behaviour is exact the same. Testing if 3d support is available: [root@sol /]# LIBGL_DEBUG=verbose glxinfo | grep direct libGL: screen 0 does not appear to be DRI3 capable libGL error: pci id for fd 4: 80ee:beef, driver (null) libGL: OpenDriver: trying /usr/lib/dri/tls/vboxvideo_dri.so libGL: OpenDriver: trying /usr/lib/dri/vboxvideo_dri.so libGL: driver does not expose __driDriverGetExtensions_vboxvideo(): /usr/lib/dri/vboxvideo_dri.so: undefined symbol: __driDriverGetExtensions_vboxvideo libGL error: core dri or dri2 extension not found libGL error: failed to load driver: vboxvideo libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so libGL: Can't open configuration file /root/.drirc: No such file or directory. libGL: Can't open configuration file /root/.drirc: No such file or directory. function is no-op function is no-op function is no-op function is no-op function is no-op function is no-op [root@sol /]# I'm no expert in tracking down that problem, just a hint that there were some reports upstream, too (but using ubuntu) https://www.virtualbox.org/ticket/12941?cversion=0&cnum_hist=8
I'd say it depends, e.g. when enabling 3D acceleration then stuff that requires OpenGL support like sddm will not start, also X will not start then. I'm not convinced this is an issue with our X server, probably more with our vboxadditions or x11-driver-video-vboxvideo packages. As when using the same X server with upstream additions, it works just fine. After uninstalling all of our vbox addition packages via "urpme -a vbox" and installing directly the Oracle guest additions via the menu "devices => insert guest additions" and then successfully running "sh VBoxLinuxAdditions.run" and rebooting, it does show "Chromium" as renderer in glxinfo, which is expected when hardware acceleration is enabled and working: [user@localhost]â[17:00:43]â[~] glxinfo 2>/dev/null|grep -iE "vendor|string" server glx vendor string: Chromium server glx version string: 1.3 Chromium client glx vendor string: Chromium client glx version string: 1.3 Chromium OpenGL vendor string: Humper OpenGL renderer string: Chromium OpenGL version string: 2.1 Chromium 1.9 OpenGL shading language version string: 4.50 NVIDIA GL_CR_print_string, GL_CR_readback_barrier_size, GL_CR_saveframe, Full output including warnings would be [user@localhost]â[17:02:08]â[~] LIBGL_DEBUG=verbose glxinfo 2>&1 | grep -iP "libGL|opengl|error|warning" libGL: OpenDriver: trying /usr/lib64/dri/tls/vboxvideo_dri.so libGL: OpenDriver: trying /usr/lib64/dri/vboxvideo_dri.so OpenGL Warning: glFlushVertexArrayRangeNV not found in mesa table OpenGL Warning: glVertexArrayRangeNV not found in mesa table OpenGL Warning: glCombinerInputNV not found in mesa table OpenGL Warning: glCombinerOutputNV not found in mesa table OpenGL Warning: glCombinerParameterfNV not found in mesa table OpenGL Warning: glCombinerParameterfvNV not found in mesa table OpenGL Warning: glCombinerParameteriNV not found in mesa table OpenGL Warning: glCombinerParameterivNV not found in mesa table OpenGL Warning: glFinalCombinerInputNV not found in mesa table OpenGL Warning: glGetCombinerInputParameterfvNV not found in mesa table OpenGL Warning: glGetCombinerInputParameterivNV not found in mesa table OpenGL Warning: glGetCombinerOutputParameterfvNV not found in mesa table OpenGL Warning: glGetCombinerOutputParameterivNV not found in mesa table OpenGL Warning: glGetFinalCombinerInputParameterfvNV not found in mesa table OpenGL Warning: glGetFinalCombinerInputParameterivNV not found in mesa table OpenGL Warning: glDeleteFencesNV not found in mesa table OpenGL Warning: glFinishFenceNV not found in mesa table OpenGL Warning: glGenFencesNV not found in mesa table OpenGL Warning: glGetFenceivNV not found in mesa table OpenGL Warning: glIsFenceNV not found in mesa table OpenGL Warning: glSetFenceNV not found in mesa table OpenGL Warning: glTestFenceNV not found in mesa table libGL: driver does not expose __driDriverGetExtensions_vboxvideo(): /usr/lib64/dri/vboxvideo_dri.so: undefined symbol: __driDriverGetExtensions_vboxvideo libGL error: core dri or dri2 extension not found libGL error: failed to load driver: vboxvideo libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so libGL: Can't open configuration file /home/user/.drirc: No such file or directory. libGL: Can't open configuration file /home/user/.drirc: No such file or directory. OpenGL vendor string: Humper OpenGL renderer string: Chromium OpenGL version string: 2.1 Chromium 1.9 OpenGL shading language version string: 4.50 NVIDIA OpenGL extensions: ---- FWIW, the error messages which are mentioned pretty often, like in Xorg.0.log > (EE) AIGLX error: vboxvideo does not export required DRI extension > (EE) AIGLX: reverting to software rendering or when running glxinfo > libGL: driver does not expose __driDriverGetExtensions_vboxvideo(): /usr/lib64/dri/vboxvideo_dri.so: undefined symbol: __driDriverGetExtensions_vboxvideo > libGL error: core dri or dri2 extension not found > libGL error: failed to load driver: vboxvideo are totally irrelevant and are not an error by itself, those are also shown when the 3D acceleration works. This is also mentioned by upstream https://www.virtualbox.org/ticket/12941?cversion=0&cnum_hist=8#comment:90 Will try to have a look at x11-driver-video-vboxvideo
Hardware: i586 => AllSummary: X11 crashes in a virtualbox guest with cauldron (4) installed => virtualbox guest with 3D acceleration enabled does not provide hardware acceleration ( since mga4 )Keywords: NEEDINFO => (none)
When it fails, can you check if vboxvideo kernel module is loaded ?
CC: (none) => tmb
Yes, was always loaded, there's also no error in dmesg. [user@localhost]â[23:40:21]â[~] dmesg|grep vbox [ +0.000071] vboxguest: misc device minor 56, IRQ 20, I/O port d020, MMIO at 00000000f0400000 (size 0x400000) [ +0.000001] vboxguest: Successfully loaded version 5.0.12_OSE (interface 0x00010004) [ +0.027045] vboxsf: Successfully loaded version 5.0.12_OSE (interface 0x00010004) [ +0.030847] [drm] Initialized vboxvideo 1.0.0 20090303 for 0000:00:02.0 on minor 0 [user@localhost]â[23:40:28]â[~] /sbin/lsmod|grep vbox vboxvideo 16384 1 drm 352256 3 vboxvideo vboxsf 49152 0 vboxguest 278528 8 vboxsf [user@localhost]â[23:40:46]â[~] FWIW I'd like to try a virtualbox build without the mesa patch that supposedly comes from Fedora (although fedora doesn't even have a virtualbox package, so I'm assuming tv and you rebased from rpmfusion - http://cvs.rpmfusion.org/viewvc/rpms/VirtualBox/devel/?root=free ? ) but virtualbox fails to compile for me locally, no matter whether under cauldron or mga5, seems an issue with the upstream kmk script/buildsystem ... And from what I can see, the mesa patch we use from rpmfusion is for virtualbox 4.3 and we have 5.0. Also most of the patch shouldn't be necessary with the changes commited upstream for this (based on the patch from rpmfusion) Looking at the history of the previously reported bugs, this issue was reported fixed shortly after you pushed 4.2.12 plus fixes. And directly after that, this mesa patch was added instead as a fix, which is probably when things broken again: http://svnweb.mageia.org/packages?view=revision&revision=410736
Seems debian also uses a much smaller patch then we do, and that is against 5.0.12: https://sources.debian.net/patches/patch/virtualbox/5.0.12-dfsg-1/18-system-xorg.patch/ They also only patch the Makefiles, we directly patch the upstream "fake" dri driver ... which seems to be the thing that is broken, after all.
Yeah, I've been meaning to do a new review the mesa stuff, but -ENOTIME so far... I will check the debian way tomorrow, and if I'm happy with it push it both cauldron and mga5
(In reply to Thomas Backlund from comment #14) > Yeah, I've been meaning to do a new review the mesa stuff, but -ENOTIME so > far... > Let me try my luck first, I've already found some other issues when rebuilding locally. FWIW upstream recently also added/removed this: https://www.virtualbox.org/changeset/59194/vbox/trunk/src/VBox/Additions/x11/vboxvideo IIUC they even added headers from mesa 11.0.7 already as they seem to be currently implementing EGL support for guests, see https://www.virtualbox.org/changeset/59109/vbox
Did a _lot_ of builds and tests with the "upstream" driver vs. the way we do it, and both have negative effects. When using the upstream driver, whether built via our package or installed via VBoxLinuxAdditions.run, the result is e.g. that lxqt-panel shows up completely black or completely transparent (but still useable). When using "our" vboxvideo dri/GL driver then e.g. sddm does not start. In both cases the performance is the same as only using software rendering. This seems to be the same for most other major distros, like *buntu/debian, fedora and openSUSE. FWIW, debian, openSUSE and ROSA all use the same patch for building vboxvideo against system libraries: https://sources.debian.net/patches/patch/virtualbox/5.0.12-dfsg-1/18-system-xorg.patch/ https://build.opensuse.org/package/view_file/openSUSE:Factory/virtualbox/virtualbox-system-x.patch?expand=1 https://abf.rosalinux.ru/current/virtualbox/blob/master/VirtualBox-5.0.0-xserver_guest.patch And our patch VirtualBox-5.0.0-mesa.patch should probably be split up into at least two patches, the first that simply contains what everybody else uses to ease syncing and the second for the parts we patch the mesa table/functions of the dri driver (maybe even a comment on why we do that, as we end up using mesa software rendering via gallium/llvmpipe instead of hardware acceleration). @Thomas: Please have a look at this, I'm out of ideas. I've added some conditionals and fixes to virtualbox and commited those as http://svnweb.mageia.org/packages?view=revision&revision=916641 Please feel free to revert or beat on me :)
Also in general the issue reported in comment 0 and in bug 9716, which is about the vboxvideo driver not allowing X to start at all, is old and doesn't exist anymore, and different from the one that this is about, missing or broken OpenGL acceleration.
Hello , with VirtualBox-5.0.18 came many changes on guest-additions , so I' here to try to help you. Mageia VirtualBox-5.0.0-mesa.patch [1] was made by me but I drop it soon I talk with VirtualBox team and they said to me this line disable 3D [2] : - vboxPatchMesaGLAPITable(); + //vboxPatchMesaGLAPITable(); [1] http://cvs.rpmfusion.org/viewvc/rpms/VirtualBox/F-18/VirtualBox-4.3.6-mesa.patch?revision=1.1&root=free&view=markup [2] https://www.virtualbox.org/pipermail/vbox-dev/2014-March/012152.html So I feel a little guilt :), and we are open source, so we don't have problems with copies . The good news is with VirtualBox-5.0.18, we can remove all bundle sources, Tomorrow I will continue writing shortly we need remove %{_libdir}/xorg/modules/drivers/* and %{_libdir}/dri/* and build with mesa-libEGL-devel , my development is here: https://github.com/sergiomb2/VirtualBox/commits/devel best regards.
CC: (none) => sergio
(In reply to Sérgio Basto from comment #18) > Mageia VirtualBox-5.0.0-mesa.patch [1] was made by me but I drop it soon I > talk with VirtualBox team and they said to me this line disable 3D [2] : > > - vboxPatchMesaGLAPITable(); > + //vboxPatchMesaGLAPITable(); > > > [1] > http://cvs.rpmfusion.org/viewvc/rpms/VirtualBox/F-18/VirtualBox-4.3.6-mesa. > patch?revision=1.1&root=free&view=markup > > [2] https://www.virtualbox.org/pipermail/vbox-dev/2014-March/012152.html > > So I feel a little guilt :), and we are open source, so we don't have > problems with copies . No need to feel guilty, and thanks for the feedback here - greatly appreciated. Will try to take a look for VirtualBox-5.0.18 and the changes you mentioned.
Assignee: bugsquad => doktor5000Status: NEW => ASSIGNED
I finally finish all fixes [1], I hope. I did a lot of git push --force , be sure that you look at latest version ... [1] https://github.com/sergiomb2/VirtualBox/commits/devel Best regards.
Just stumbled on this bug report and see it seem to be forgotten - Status?
CC: (none) => fri
This can be closed
Hello , for "full" 3D acceleration see the new developments on https://src.fedoraproject.org/rpms/virtualbox-guest-additions/tree/master https://src.fedoraproject.org/rpms/virtualbox-guest-additions/blob/master/f/VBoxOGLRun.sh i.e. we (in Fedora) don't enable 3D by default in boot because 3D is limited and have a few bugs , but we can can or try to run 3D apps with VBoxOGLRun.sh
We are going to drop the vboxadditions packages in cauldron/mga7 as all needed bits are landing in upstream kernel.org kernel and the vboxvideo ddx is now also provided/maintained as an upstream xorg ddx so we'll see how it goes then...
kernel bits for vboxvideo.ko and vboxguet.ko are upstream , but vboxsf.ko still under review, you still need the rest of the code vboxservice etc ... https://bugzilla.redhat.com/show_bug.cgi?id=1481630
This bug was filed against Mageia 4 which is EOL since Sep 2015.
Resolution: (none) => OLDStatus: ASSIGNED => RESOLVED
Hi, BTW FYI, virtualbox 3d accel bits is known to be broken and will be removed on next version of VirtualBox, VirtualBox 7 , for more references https://bugzilla.redhat.com/show_bug.cgi?id=2105729#c17