FS#33229 - [xorg-server] virtualbox X hangs on start in Arch guest install after updating to glibc-2.17

Attached to Project: Arch Linux
Opened by Josh Braun (wideaperture) - Friday, 28 December 2012, 19:47 GMT
Last edited by Jan de Groot (JGC) - Monday, 18 February 2013, 15:58 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Jan de Groot (JGC)
Andreas Radke (AndyRTR)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 22
Private No

Details

Description:

Updating to the package versions listed in the next section causes X to hang when started. I am running Arch in VirtualBox 4.2.6 on an OS X 10.7.5 host. The latest version of virtualbox-guest-utils (4.2.6-1) and virtualbox-guest-modules (4.2.6-3) are installed through the Arch repository. The system boots just fine, but my Gnome desktop won't launch. The screen goes black and hangs, the resolution never changes either. I'm using "~/.xinitrc:exec gnome-session" and 'startx' to launch the desktop environment, rather than gdm.

At least one other user has experienced a similar issue: https://bbs.archlinux.org/viewtopic.php?pid=1211131


Additional info:
* package version(s):

Rolling back these four packages to previous versions after the update fixed the issue, so I'm assuming the conflict has to do with them and another element of the desktop environment (X, Guest Additions, or possibly Gnome):

binutils-2.23.1-2
gcc-4.7.2-3
gcc-libs-4.7.2-3
glibc-2.17-1

Here are the other relevant packages...

Installed Virtualbox Guest Additions packages:

virtualbox-guest-utils (4.2.6-1)
virtualbox-guest-modules (4.2.6-3)

Installed Xorg packages:

xorg-xsetroot 1.1.0-3
xorg-xset 1.2.2-1
xorg-xrefresh 1.0.4-3
xorg-xrdb 1.0.9-2
xorg-xrandr 1.3.5-1
xorg-xmodmap 1.0.7-1
xorg-xkbcomp 1.2.4-1
xorg-xinput 1.6.0-1
xorg-xinit 1.3.2-3
xorg-xhost 1.0.5-1
xorg-xgamma 1.0.5-1
xorg-xcmsdb 1.0.4-1
xorg-xclock 1.0.6-1
xorg-xbacklight 1.2.0-1
xorg-xauth 1.0.7-1
xorg-twm 1.0.7-1
xorg-setxkbmap 1.3.0-1
xorg-sessreg 1.0.7-1
xorg-server-utils 7.6-3
xorg-server-common 1.13.1-1
xorg-server 1.13.1-1
xorg-mkfontscale 1.1.0-1
xorg-mkfontdir 1.0.7-1
xorg-luit 1.1.1-1
xorg-iceauth 1.0.5-1
xorg-fonts-misc 1.0.1-2
xorg-fonts-encodings 1.0.4-3
xorg-fonts-alias 1.0.2-2
xorg-font-utils 7.6-3
xorg-font-util 1.3.0-1
xorg-bdftopcf 1.0.3-2
xf86-input-evdev 2.7.3-2

Lastly, while I'm pretty sure X is hanging before it ever gets around to starting a gnome session, here are the version numbers of my gnome packages just in case they're relevant:

yelp 3.6.2-1
xdg-user-dirs-gtk 0.9-1
polkit-gnome 0.105-1
notification-daemon 0.7.6-1
network-manager-applet 0.9.6.4-1
nautilus 3.6.3-1
mutter 3.6.2-1
metacity 2.34.13-1
libsoup-gnome 2.40.2-1
libsoup 2.40.2-1
libreoffice-gnome 3.6.4-3
libgsf 1.14.25-1
libgnomeui 2.24.5-1
libgnomekbd 3.6.0-1
libgnomecanvas 2.30.3-2
libgnome-media-profiles 3.0.0-3
libgnome-keyring 3.6.0-1
libgnome-data 2.32.1-3
libgnome 2.32.1-3
icon-naming-utils 0.8.90-2
gtksourceview3 3.6.1-1
gnome-video-effects 0.4.0-2
gnome-vfs 2.24.4-6
gnome-user-docs 3.6.2-1
gnome-tweak-tool 3.6.1-1
gnome-themes-standard 3.6.2-1
gnome-terminal 3.6.0-1
gnome-speech 0.4.25-2
gnome-shell 3.6.2-1
gnome-settings-daemon 3.6.3-2
gnome-session 3.6.2-1
gnome-screensaver 3.6.1-1
gnome-panel 3.6.2-1
gnome-online-accounts 3.6.2-1
gnome-mime-data 2.18.0-6
gnome-menus 3.6.1-1
gnome-keyring 3.6.2-1
gnome-icon-theme-symbolic 3.6.2-1
gnome-icon-theme-extras 3.6.2-1
gnome-icon-theme 3.6.2-1
gnome-desktop 1:3.6.2-1
gnome-control-center 3.6.3-3
gnome-bluetooth 3.6.1-1
gnome-backgrounds 3.6.0-1
gjs 1.34.0-1
gdm 3.6.2-1
epiphany 3.6.1-1
caribou 0.4.4.2-1
brasero 3.6.1-1

* config and/or log files etc.

Xorg.0.log: http://pastie.org/5589544
System update excerpt from pacman.log: http://pastie.org/5589541

Steps to reproduce:

Update to the following packages in a VirtualBox Arch installation running the gnome desktop environment and VirtualBox Guest Additions (other relevant version numbers above):

binutils-2.23.1-2
gcc-4.7.2-3
gcc-libs-4.7.2-3
glibc-2.17-1
This task depends upon

Closed by  Jan de Groot (JGC)
Monday, 18 February 2013, 15:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  The suggested patch has been implemented. Upstream has not responded to the bugreport so far, but besides an extra line of code, this patch is harmless.
Comment by patrick (potomac) - Friday, 28 December 2012, 23:11 GMT
I confirm the bug in virtualbox, I use KDE, archlinux 32 bits,

the culprit seems to be the packages "virtualbox-guest-modules 4.2.6-3" and "virtualbox-guest-utils 4.2.6-1" who seem not compatible with the last version of glibc ( 2.17-1 ),

I disable the virtualbox modules in /etc/modules-load.d/ and disable the virtualbox service with systemctl, then I can now start KDE,

a rebuild of these packages may fix the problem
Comment by Josh Braun (wideaperture) - Saturday, 29 December 2012, 17:20 GMT Comment by Dave Reisner (falconindy) - Saturday, 29 December 2012, 23:08 GMT
> a rebuild of these packages may fix the problem

You're in the best position to test that theory, though it's highly dubious that this would be a problem. If a rebuild fixes this, I'd almost say that glibc is broken for not maintaining backwards compat.
Comment by patrick (potomac) - Sunday, 30 December 2012, 16:41 GMT
I made a rebuilt of the "virtualbox-guest-modules" but it doesn't fix the problem
Comment by Zrianc (zrianc) - Monday, 31 December 2012, 09:27 GMT
I have the same problem, temporary solved by downgrading glibc 2.17-1 to 2.16.0-5 (and dependencies).
I use lxde with the lxdm service enabled.
Maybe the bug is in the new version of glibc?

Edited to add:
I recompiled virtualbox-guest-utils and virtualbox-guest-modules from ABS while using glibc 2.17-1 and the problem remains unsolved.
Comment by Josh Braun (wideaperture) - Monday, 31 December 2012, 15:08 GMT
I filed this bug as being of 'medium' severity, but perhaps it should be 'high', since it interferes with X's essential functioning. Should/could it be escalated by a good samaritan?
Comment by Where are the (hagfish) - Tuesday, 01 January 2013, 15:56 GMT
I can confirm this bug in virtualbox, and believe it should be rated as 'high', as it makes it impossible to starts a window manager or a desktop environment, which many rely on for everyday computing. Downgrading binutils-2.23.1-2, gcc-4.7.2-3, gcc-libs-4.7.2-3 and glibc-2.17-1 fixes the bug for me, but creates problems with installing other packages (such as splashy-full).
Comment by Benjamin Robin (benjarobin) - Wednesday, 02 January 2013, 10:29 GMT
To downgrade easily, I added : "Server = http://arm.konnichi.com/2012/12/28/$repo/os/$arch/" to the top of my /etc/pacman.d/mirrorlist, then "pacman -Syyuu"

Does the bug is reported upstream ?
Comment by Josh Braun (wideaperture) - Wednesday, 02 January 2013, 12:50 GMT
> Does the bug is reported upstream ?

I've only posted it here, as I was unsure whether the underlying issue was with Arch, glibc, X, or VirtualBox Guest Additions.
Comment by Shi Zhan (eshizhan) - Thursday, 03 January 2013, 08:02 GMT
same problem, I disable vboxvideo module, works.
Comment by Josh Braun (wideaperture) - Thursday, 03 January 2013, 15:24 GMT
I have reported this bug to the VirtualBox bug tracker: https://www.virtualbox.org/ticket/11356
Comment by Benjamin Robin (benjarobin) - Thursday, 03 January 2013, 15:31 GMT
Great report, but could you add/set the "Guest type"
Comment by Josh Braun (wideaperture) - Thursday, 03 January 2013, 15:35 GMT
Thanks. It's a 32-bit Arch guest. The VM is saved using a .VDI filetype. Is this what you mean?
Comment by Benjamin Robin (benjarobin) - Thursday, 03 January 2013, 15:39 GMT
No, I mean the parameter in the header of the report. You can find "Version:" , "Component:" , "Host type:" , ... and "Guest type:"
I guess you can specify this parameter because you are the owner of this ticket
Comment by Josh Braun (wideaperture) - Thursday, 03 January 2013, 15:49 GMT
Ah! I see what you're saying. I totally missed that field. Unfortunately, despite being the ticket owner, I apparently do not have "ticket-modify" permissions on the VB Trac system. I can click "Modify," but the form I get in response is empty.
Comment by Matteo Agostinelli (matteo81) - Monday, 07 January 2013, 16:30 GMT
same problem here. downgrading glibc, binutils, gcc, gcc-libs works
Comment by Allan McRae (Allan) - Tuesday, 08 January 2013, 13:40 GMT
If disabling the virtualbox guest additions video driver is enough to work around this issue, I will lay the blame on virtualbox and not glibc.

If someone wants to prove me wrong, bisect the glibc commit that causes the issue and I will look at it. At this stage, I will not be doing so...
Comment by Shi Zhan (eshizhan) - Wednesday, 09 January 2013, 01:23 GMT Comment by Frederico Garcia (Jaaroy) - Wednesday, 09 January 2013, 10:31 GMT
32-bit version issues this bug
Comment by Benjamin Robin (benjarobin) - Wednesday, 09 January 2013, 21:45 GMT
I did run the git bisect on glibc between 2.16 and 2.17. Here the steps of the bisect: http://pastebin.com/37JfBUuM

The offender commit is c78ab0947353c8f46d23857ebf3fb4a70ed581d9 (Cleanup code duplication in malloc on fallback to use another arena...)

I will try to revert only this commit in version 2.17
Comment by Benjamin Robin (benjarobin) - Wednesday, 09 January 2013, 22:18 GMT
Quick update: I did checkout this version : git log | head
commit c40ea3d9a3be8645441967cddf14645b84af5f2c
Date: Tue Jan 8 19:32:00 2013 +0100

Then revert: git revert c78ab0947353c8f46d23857ebf3fb4a70ed581d9

git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: malloc/arena.c
# modified: malloc/malloc.c

===> Virtualbox is working without problem :-)

Now I will try to understand why, and what is going on with this commit.
I am not an expert, if anybody can take a look and/or try without the offender commit to confirm my tests, thanks

The offender commit can be seen here: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=c78ab0947353c8f46d23857ebf3fb4a70ed581d9;hp=01f49f59cebf782c663698a0fa6f15453409d42b
Comment by Allan McRae (Allan) - Wednesday, 09 January 2013, 22:28 GMT
Thanks - I am looking into this and will follow-up with upstream glibc.
Comment by Benjamin Robin (benjarobin) - Wednesday, 09 January 2013, 22:29 GMT
Well, in the mean time, if somebody confirm my test, it will be great to revert this commit as soon as possible: This is just a clean up commit to improve readability. Reverting cannot break glibc.
Comment by Allan McRae (Allan) - Wednesday, 09 January 2013, 22:46 GMT
Can you try reverting just the last section?

@@ -3225,22 +3173,10 @@ __libc_calloc(size_t n, size_t elem_size)
Comment by Benjamin Robin (benjarobin) - Wednesday, 09 January 2013, 22:57 GMT
Result in less that 20 min... (My hard drive of my core i7 died, waiting to be replaced... Compiling with a core2duo ULV U7300 @1.30GHz, sorry for the delay)
Comment by Allan McRae (Allan) - Wednesday, 09 January 2013, 23:02 GMT
Hmm... ignore that. It is just a less obvious refactor too.
Comment by Benjamin Robin (benjarobin) - Wednesday, 09 January 2013, 23:09 GMT
I can confirm that reverting only this point is not fixing it
Comment by Allan McRae (Allan) - Wednesday, 09 January 2013, 23:13 GMT
Bah! You'd think one of those sections has got to have something wrong with it... but I can not spot it.
Comment by Benjamin Robin (benjarobin) - Wednesday, 09 January 2013, 23:18 GMT
Me neither, we need a clean glibc 2.17 without the commit and tester to confirm the issue and my test. Right now I am only building the library not the applications and I create a package installed on the top of current glibc using option "-Uf"...

I do not have time "today" (in France this is already tomorrow 00:20) to build a clean package
Comment by Allan McRae (Allan) - Wednesday, 09 January 2013, 23:52 GMT
Can anyone confirm this package fixes the issue:
http://pkgbuild.com/~allan/glibc-2.17-1.1-i686.pkg.tar.xz
Comment by Javier Tiá (jetm) - Thursday, 10 January 2013, 00:54 GMT
Allan,

http://pkgbuild.com/~allan/glibc-2.17-1.1-i686.pkg.tar.xz worked fine for me.

Tested on Guest Arch Linux with vboxguest, vboxsf and vboxvideo modules loaded.



Comment by Allan McRae (Allan) - Thursday, 10 January 2013, 02:16 GMT
Great - that confirms the commit that introduced this issue. Now which one of these breaks?

http://pkgbuild.com/~allan/glibc-2.17-1.2-i686.pkg.tar.xz
http://pkgbuild.com/~allan/glibc-2.17-1.3-i686.pkg.tar.xz
Comment by Javier Tiá (jetm) - Thursday, 10 January 2013, 02:24 GMT Comment by Allan McRae (Allan) - Thursday, 10 January 2013, 03:01 GMT Comment by Javier Tiá (jetm) - Thursday, 10 January 2013, 03:10 GMT Comment by Allan McRae (Allan) - Thursday, 10 January 2013, 04:08 GMT
The final good package reverted just this from glibc commit c78ab094:

@@ -2858,23 +2858,10 @@ __libc_malloc(size_t bytes)
Comment by Allan McRae (Allan) - Thursday, 10 January 2013, 06:19 GMT
  • Field changed: Summary (X hangs on start in VirtualBox Arch install after updating to binutils-2.23.1-2, gcc-4.7.2-3 → [virtualbox] X hangs on start in Arch guest install after updating to glibc-2.17)
  • Field changed: Attached to Project (Arch Linux → Community Packages)
  • Assignment removed
If that commit was broken, we be seeing issues all over the place... so leaving as a virtualbox issue.
Comment by Allan McRae (Allan) - Monday, 14 January 2013, 13:55 GMT Comment by Josh Braun (wideaperture) - Monday, 14 January 2013, 14:29 GMT
That worked for me! Since I'm still not a power user, though, I want to make sure I tested everything correctly. These were my steps:

(1) Removed 'IgnorePkg binutils gcc gcc-libs glibc' from pacman.conf
(2) Ran pacman -Syu to upgrade to the latest repository versions of the above (all other packages were already up to date).
(3) Downloaded the glibc package you provided.
(3) Ran 'pacman -U /path/to/new/glibc/package' to overwrite repository version of the glibc package.
(4) Rebooted.
(5) Launched successfully into Gnome from the command line. Did the same with Awesome WM for good measure.
Comment by Josh Braun (wideaperture) - Monday, 14 January 2013, 14:41 GMT
Ah, and if it's not obvious from the above, I'd previously rolled back glibc and dependencies to previous versions and kept the vboxvideo module active. So, in the above test, the reason there's no point at which I turned vboxvideo back on is because I'd kept using it the whole time.
Comment by Philip Müller (philm) - Monday, 14 January 2013, 15:51 GMT
I can confirm that glibc-2.17-1.6 also works for Manjaro Linux. Successfully started Manjaro-Openbox x32 on a Manjaro-XFCE x32 host.
I hope we find a proper solution to this rare issue soon.
Comment by Benjamin Robin (benjarobin) - Monday, 14 January 2013, 16:19 GMT
@Allan What is the patch that you tried ? Can this be a glibc issue ?
Comment by Allan McRae (Allan) - Monday, 14 January 2013, 22:00 GMT
In that package, I revert this part of the problem patch:

@@ -2858,23 +2858,10 @@ __libc_malloc(size_t bytes)

and added a

if (__builtin_expect(ar_ptr != NULL, 1)) {

where one gets added in the patch. Now I have no idea...
Comment by Dirk Kredler (DirkKredler) - Wednesday, 16 January 2013, 15:52 GMT
This package worked for me: http://pkgbuild.com/~allan/glibc-2.17-1.6-i686.pkg.tar.xz

Host: Mac OS X 10.8.2
VirtualBox 4.2.6 r82870 (at the time of writing the current version)
Arch Linux 3.6.11-1-ARCH #1 SMP PREEMPT Tue Dec 18 12:58:46 CET 2012 i686 GNU/Linux

before i did a "pacman -Syu" and the Arch Linux system did crash / hang on X11; after this i booted in Runlevel 3 and
updated the glibc package with the version above and now the system starts correctly :-)

Comment by Zrianc (zrianc) - Wednesday, 16 January 2013, 15:56 GMT
Maybe until this problem is fixed https://wiki.archlinux.org/index.php/VirtualBox#Install_the_Guest_Additions should be updated to recomend not to enable vboxvideo.

Also I found that there are some (other) stability problems with vboxvideo in the latest versions of ubuntu and fedora that use xorg 1.13, and at least in lubuntu 12.10 it's disabled by default.
Look for example at this thread: https://forums.virtualbox.org/viewtopic.php?f=3&t=51727&start=30
Comment by Kristian (korov2000) - Saturday, 19 January 2013, 13:46 GMT
This package worked for me too: http://pkgbuild.com/~allan/glibc-2.17-1.6-i686.pkg.tar.xz

Host: Windows 7 Enterprise x64
Virtualbox 4.1.8 r75467
Virtualbox-guest-utils 4.2.6-1
Arch Linux 3.6.11-1-ARCH
Comment by Josh Braun (wideaperture) - Monday, 21 January 2013, 13:22 GMT
An updated version of Guest Modules (4.2.6-4) was released today by Sébastien Luttringer. The commit message says it was in reference to https://bugs.archlinux.org/task/33194. Anyone know if it has any effect on this issue as well? (Probably not, but thought I'd ask.)
Comment by Allan McRae (Allan) - Monday, 21 January 2013, 13:25 GMT Comment by patrick (potomac) - Monday, 21 January 2013, 14:53 GMT
the new version of guest modules (4.2.6-4) is not Ok, there is no black screen but the vboxvideo driver failed to be loaded, I got a "failed" status in systemd :

Jan 21 15:46:44 localhost kernel: [ 2.923713] vboxvideo: disagrees about version of symbol drm_pci_init
Jan 21 15:46:44 localhost kernel: [ 2.923717] vboxvideo: Unknown symbol drm_pci_init (err -22)
Jan 21 15:46:44 localhost kernel: [ 2.923722] vboxvideo: disagrees about version of symbol drm_vblank_init
Jan 21 15:46:44 localhost kernel: [ 2.923724] vboxvideo: Unknown symbol drm_vblank_init (err -22)
Jan 21 15:46:44 localhost kernel: [ 2.923726] vboxvideo: disagrees about version of symbol drm_pci_exit
Jan 21 15:46:44 localhost kernel: [ 2.923727] vboxvideo: Unknown symbol drm_pci_exit (err -22)

Jan 21 15:46:44 localhost [ 2.945356] systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE
Jan 21 15:46:44 localhost [ 2.951883] systemd[1]: Unit systemd-modules-load.service entered failed state

for me this version is not really a fix
Comment by Benjamin Robin (benjarobin) - Monday, 21 January 2013, 14:57 GMT
Who said that 4.2.6-4 is going to fix it ? Did you update the whole system ? Are you running with linux 3.7.3 ?

@Allan Did you have any advice to track this bug, my computer is now fixed and I can run some test, I was thinking by using the valgrind tools, advise ?
Comment by patrick (potomac) - Monday, 21 January 2013, 14:59 GMT
to Benjamin Robin: yes I run with linux 3.7.3
Comment by Josh Braun (wideaperture) - Monday, 21 January 2013, 15:01 GMT
To clarify, Allan said above (and the commit comments on 4.2.6-4 also state) that 4.2.6-4 fixes a different bug, but not this one. So its purpose was not to repair the glibc conflict.
Comment by Benjamin Robin (benjarobin) - Monday, 21 January 2013, 20:19 GMT
@potomac Well, you was right, the new virtualbox-guest-modules-4.2.6-4 is buggy, I did recompile the package and everything works fine (With the patched glibc). I will reopen the ticket for virtualbox-guest-modules
Comment by Josh Braun (wideaperture) - Wednesday, 23 January 2013, 16:07 GMT
The folks over on the VirtualBox bug tracking system have been looking at this problem as well and there appears to be some valuable information there, however I don't have the appropriate technical expertise to interpret it or respond adequately. Perhaps someone else could take a look and/or add their two cents:

https://www.virtualbox.org/ticket/11356

Take a look at comment 8 in particular.
Comment by Josh Braun (wideaperture) - Thursday, 24 January 2013, 12:11 GMT
Thanks so much, Benjamin Robin, for checking in on the VirtualBox thread. There's another reply there now; the gist is that they're suggesting the issue is with Xorg—specifically with libglx.so—and, "If the Arch Linux people still think that this is a VirtualBox bug, it would be nice if one of them with experience at debugging the X server packages could comment on this ticket so that we can investigate the issue together."
Comment by Benjamin Robin (benjarobin) - Thursday, 24 January 2013, 19:07 GMT
I got this backtrace : http://pastebin.com/Rh7X6bdt
I am going to compile the library with symbol to obtain a better back trace
Edit, Trace with symbol : http://pastebin.com/iJzw4edM
Comment by Benjamin Robin (benjarobin) - Thursday, 24 January 2013, 21:11 GMT
Found the bug :-) :-) :-)

Add : "framebuffer.base = NULL;" into glxdri.c at line 974
Comment by Allan McRae (Allan) - Thursday, 24 January 2013, 21:18 GMT
Just because I am lazy... Can you clarify, glxdri.c in what package?
Comment by Benjamin Robin (benjarobin) - Thursday, 24 January 2013, 21:19 GMT
And no your are not lazy (sorry forget to mention the name of the package), you are just faster than my edit : I am writing the patch right now :-)

The bug is inside xorg-server, patch here: http://pastebin.com/Dt6wvdAp
Comment by Benjamin Robin (benjarobin) - Thursday, 24 January 2013, 21:47 GMT
I do report this bug upstream : https://bugs.freedesktop.org/show_bug.cgi?id=59825 (I hope information are understandable and enough detailed)
Comment by Andreas Radke (AndyRTR) - Friday, 25 January 2013, 09:06 GMT
CC'ed to to the upstream bug. Let's see if they think this is the proper fix.
Comment by Josh Braun (wideaperture) - Sunday, 27 January 2013, 15:03 GMT
After updating to glibc 2.17-2 and xorg-server 1.13.2-1, X appears to be loading okay without any workarounds. However, this may also be because the vboxvideo module does *not* appear to be loading correctly at this point (ever since the January 21 update to virtualbox-guest-modules 4.2.6-4). So in other words, the module having the conflict may simply not be loading right now. On startup, I'm getting the same error messages as Patrick above (https://bugs.archlinux.org/task/33229#comment104953), wherein a 'failed' status appears when systemd attempts to load the module during boot, and the following errors show up in the dmesg output:

[ 5.435378] vboxvideo: disagrees about version of symbol drm_pci_init
[ 5.435385] vboxvideo: Unknown symbol drm_pci_init (err -22)
[ 5.435394] vboxvideo: disagrees about version of symbol drm_vblank_init
[ 5.435396] vboxvideo: Unknown symbol drm_vblank_init (err -22)
[ 5.435402] vboxvideo: disagrees about version of symbol drm_pci_exit
[ 5.435404] vboxvideo: Unknown symbol drm_pci_exit (err -22)
Comment by Benjamin Robin (benjarobin) - Sunday, 27 January 2013, 17:38 GMT
I do report this bug https://bugs.archlinux.org/task/33598

For the bug inside xorg-server, do we really need to wait upstream to fix it ?
If anyone think of a better correction ? Mine does have any impact, it just initialized to NULL a local variable...
Comment by Josh Braun (wideaperture) - Thursday, 31 January 2013, 00:02 GMT
The good news is that upon upgrading to linux 3.7.5-1 and virtualbox-guest-modules 4.2.6-5, the VirtualBox video module now loads, which solves  bug 33598 . The bad news is that this bug is back—now that the video module is loading, it's resuming its spitting contest with xserver.
Comment by Pierre Schmitz (Pierre) - Thursday, 31 January 2013, 19:46 GMT
@Benjamin Robin: Thanks for debugging this.

As I needed a working vbox for myself I have build and uploaded signed packages with this patch applied: https://users.archlinux.de/~pierre/tmp/ It's possible this will get fixed in the repos as well soon.

Loading...