Fedora 17 Alpha - Fails OpenGL and not installing the X.Org drivers

[Moyogo]

When trying to install VirtualBox 4.1.8 additions on Fedora 17 Alpha I get following messages :

Building the OpenGL support module                         [FAILED]
(Look at /var/log/vboxadd-install.log to find out what went wrong)
Doing non-kernel setup of the Guest Additions              [  OK  ]
Installing the Window System drivers
Warning: unsupported pre-release version of X.Org Server installed.  Not
installing the X.Org drivers.

X.Org version is

$ rpm -qa | grep -i xorg-X11-server
xorg-x11-server-common-1.11.99.901-6.20120124.fc17.i686
xorg-x11-server-Xorg-1.11.99.901-6.20120124.fc17.i686
xorg-x11-server-utils-7.5-10.fc17.i686
xorg-x11-server-Xephyr-1.11.99.901-6.20120124.fc17.i686

[misha]

Could you attach /var/log/vboxadd-install.log here as the err log suggests?

[Solitary]

The failed OpenGL module can be solved by this simple ​workaround

X.Org is unsupported though... which means no seamless mode or dynamic resolution :/

[Dan Mashal]

I can confirm that Solitary's workaround works, but is not an ideal solution.

​http://fpaste.org/0nP0

Also vbox svn trunk still fails to build.

​http://fpaste.org/7IDK/

[Michael Thayer]

Interesting, what make are F17 using then? (I will presumably know as soon as I have a VM installed.) Experience says that supporting a new X Server is usually slightly tedious but not a big problem. Of course we can't provide proper support for pre-releases, but I will see if I can get something working today.

[Dan Mashal]

@Michael

F17 is using the following: gmake and make are both 3.82 GCC version 4.7 Kernel version 3.3, just moved to rc6.

rpm -q xorg-x11-server-common shows the following:

xorg-x11-server-common-1.11.99.901-6.20120124.fc17.x86_64

[Solitary]

Well, X.Org 1.12 has been released and already made his way into F17. So no pre-release version anymore.

[Frank Mehnert]

Fedora 17 is NOT released yet. X.org 1.12 was released 4 days ago so you don't expect support for it in VirtualBox 4.1.8 which was released several weeks, do you?

[Solitary]

@frank

Has anybody said those alleged expectations? This bug post is about failed OpenGL module and missing support for pre-released version as a warning about upcoming issue. X.Org has been released now, so the work on support can begin.

Why do you comment, if you don't have anything useful to say? Off you go, cpt. Obvious.

[Frank Mehnert]

Solitary, my comment was to clarify that we don't support pre-releases. My impression after your last comment was that you expect that we do. And keeping that in mind I think my last comment contained more information than yours. But I don't want nit-picking.

[Dan Mashal]

Wow frank, can your attitude get any worse?

[Frank Mehnert]

I'm sorry?

[Frank Mehnert]

To clarify: We do everything to get support for new Linux/X.org/whatever releases into the VBox code. My last comments where only to underline that one cannot expect support for pre-releases because more than once we saw last-minute API changes making such attempts useless.

The tone of my initial comment to Solitary was probably a bit rude, in that case I apologize. My comment was just a result of a bit frustration, that's all.

[Dan Mashal]

You should be. It is unacceptable and offers no workaround what so ever.

I have spent probably a hundred hours troubleshooting this problem and trying to figure this out, to the point of joining fedora QA.

If you check out the latest vbox trunk and try to compile from source you will see that there are work arounds for kernel 3.2. Kernel 3.3 shouldn't be that much different and neither should the new version of X.org which is no longer a prerelease.

If you could offer a way to disable the check for the version X.org and install X.org additions anyway, a la a "FORCE" option that would be extremely helpful.

Otherwise, please delete my account here and I can uninstall VirtualBox and switch to VMware workstation/player or KVM going forward instead of having to deal with this frustration.

[Frank Mehnert]

Replying to dmashal:

You should be. It is unacceptable and offers no workaround what so ever.

I have spent probably a hundred hours troubleshooting this problem and trying to figure this out, to the point of joining fedora QA.

I can assure you that we also spent many useless hours debugging problems in pre-releases. Some X.org releases ago we put the headers for the next X.org release into the tree and a few days prior to the new Ubuntu release these guys did an API change making the whole effort useless. Just one example.

And Fedora is just another example when pre-releases are getting into a distribution when they better should use stable versions. gcc-4.7.0 is not released and they use it as default compiler for the upcoming distribution. They are free to do so and we are using that compiler internally for testing purposes as well. But we rather prefer stable APIs and stable releases.

If you check out the latest vbox trunk and try to compile from source you will see that there are work arounds for kernel 3.2. Kernel 3.3 shouldn't be that much different and neither should the new version of X.org which is no longer a prerelease.

I know, we get such kernel adaptions into the tree as soon as possible. There is even support for the upcoming Linux 3.3. But where is the point? We try to support as much as possible but we just cannot guarantee that, that's all.

If you could offer a way to disable the check for the version X.org and install X.org additions anyway, a la a "FORCE" option that would be extremely helpful.

That option is there in the X server but I would not recommend using it. Otherwise we would get more reports that something isn't working as expected inducing even more overhead. Sorry, but it is not our fault that one has to recompile the X modules for every new X.org release. We just have to live with it.

Otherwise, please delete my account here and I can uninstall VirtualBox and switch to VMware workstation/player or KVM going forward instead of having to deal with this frustration.

You should understand our frustration as well. But I fear you don't want to see that.

I know, X.org 1.12 is released and the upcoming maintenance release will contain support for it. You also might have seen the changes in trunk.

[Dan Mashal]

Klaus/Frank,

I would like to join VirtualBox QA. I know there is a way we can fix this.

Frank, in reply to giving the users an option I don't see how that would create more bugs if a warning is issued. If a user is properly warned about the complications of installing incompatible drivers, then by all means your response would have been completely justified.

[Michael Thayer]

For all concerned: the Additions have supported X.Org Server 1.12 since Monday 5th. Here is a current test build from the 4.1 branch which should work with Fedora 17 (the OpenGL thing seems to have either been fixed by Frank or gone away on its own), which I was unable to provide earlier since I wasn't available.

​http://www.virtualbox.org/download/testcase/VBoxGuestAdditions_4.1.9-76737.iso

dmashal: do I understand from your comments that the X.Org Server 1.11 driver also works with 1.12? If so it is a co-incidence - I think the last time that happened was in the XFree86 days (the mouse driver did stay binary compatible between Server 1.3 and 1.4 though for the record...) and a FORCE option is generally not sensible; as Frank wrote, the binary for (I think it was) the second 1.11 release candidate was actually incompatible with the final release. So this is not a question of QA falling short.

And regarding the dispute which took place on this ticket in the mean time, I also feel that "Why do you comment, if you don't have anything useful to say? Off you go, cpt." is an extremely disrespectful response to someone who has invested many years and countless energy into making VirtualBox what it is today. Certainly I appreciate what our user community does for us by testing VirtualBox and helping to track down problems and improve it, but the tone on this ticket could easily have been read as demanding new features on the same day. I'm not sure how many development teams for other products would have reacted this fast for paying customers.

[Andre Robatino]

I can confirm that VBoxGuestAdditions_4.1.9-76737.iso works for me with both Fedora 17 and Fedora Rawhide guests, with no need to set $MAKE to avoid the OpenGL error (although there is no longer an explicit OpenGL line when building the guest additions). Using hardware passthrough, Gnome Shell is much faster compared to using software rendering.

[Frank Mehnert]

These fixes are part of VirtualBox 4.1.10.