VMware Communities
babystrangeloop
Enthusiast
Enthusiast
Jump to solution

vmware-tools installation fails for Lucid with "No drivers for X.org version: 7.6.6."

VMware Fusion Version 3.0.2 (232708)

Ubuntu 10.04 Lucid Lynx as of Wed April 21, 2010

$ sudo /usr/local/bin/vmware-config-tools.pl

... skip ...

Detected X.org version 7.6.6.

No drivers for X.org version: 7.6.6.

Skipping X configuration because X drivers are not included.

... skip ...

0 Kudos
1 Solution

Accepted Solutions
Noel
Expert
Expert
Jump to solution

apt-get install xserver-xorg-input-vmmouse xserver-xorg-video-vmware.

The apt-get install command just tells me that I already have the latest version of these two packages installed.

But vmware-config-tools.pl still complaqins about X.org being unsupported (I guess too new).

Correct. You can ignore the Xorg related complaint from vmware-config-tools. If you check logs, you'll see that the VMware drivers, which are provided by the xserver packages, are already loaded.

Over time, VMware works to get drivers into the upstream products directly. For example, I believe that vmxnet3 has now been accepted into the linux kernel, and won't need to be distributed with future versions of VMware Tools.

View solution in original post

0 Kudos
9 Replies
Noel
Expert
Expert
Jump to solution

1) This has been addressed with newer versions of vmware tools.

2) Even without the above, there are packages for the vmware video and mouse installable directly from apt-get.

Strangelove
Contributor
Contributor
Jump to solution

I just encountered the same problem and I would like to follow your advice. However, I have to ask:

1) Where can I download the newer version of vmware tools? I am using the latest and greatest version 3.0.1 of vmware player, and it exposes the same problem.

2) How can I install those up-to-date packages in Lucid rc? I have tried apt-get update, apt-get upgrade, and finally apt-get install xserver-xorg-input-vmmouse xserver-xorg-video-vmware.

The apt-get install command just tells me that I already have the latest version of these two packages installed.

But vmware-config-tools.pl still complaqins about X.org being unsupported (I guess too new).

Any idea?

0 Kudos
Noel
Expert
Expert
Jump to solution

apt-get install xserver-xorg-input-vmmouse xserver-xorg-video-vmware.

The apt-get install command just tells me that I already have the latest version of these two packages installed.

But vmware-config-tools.pl still complaqins about X.org being unsupported (I guess too new).

Correct. You can ignore the Xorg related complaint from vmware-config-tools. If you check logs, you'll see that the VMware drivers, which are provided by the xserver packages, are already loaded.

Over time, VMware works to get drivers into the upstream products directly. For example, I believe that vmxnet3 has now been accepted into the linux kernel, and won't need to be distributed with future versions of VMware Tools.

0 Kudos
Strangelove
Contributor
Contributor
Jump to solution

Thank you for the explanation. The bottom line is that this error message can be safely ignored in a Lucid guest.

Now that I have experimented with the newly installed system, I must say that it works pretty smooth in VMware player.

The drivers seem to work well. In fact I had more quirks to solve with my dual-screen setup using native (non-virtualized) Ubuntu and fglrx drivers.

0 Kudos
babystrangeloop
Enthusiast
Enthusiast
Jump to solution

@StrangeLove - yeah, Nvidia not ATI graphics appear to be the best choice for Ubuntu now.

0 Kudos
PatCasey
Contributor
Contributor
Jump to solution

I don't think this is quite as harmless at it seems at first though. It's not a major problem, but it is fairly annoying. Let me try to explain...

When the vmware-config-tools.pl detects drivers, it offers an array of choices to select the initial screen resolution. Under Ubuntu 10.04 Lucid Lynx, since it doesn't detect the proper drivers, it no longer offers that choice. Just about everything appears to work ok, except that gdm starts up with a low screen resolution. Since the driver is unable to determine what kind of monitor is attached to the VM automatically, it chooses 800x600 since it can be virtually certain to at least work somewhat, at least long enough to get logged in.

Well, this seems like "Oh well, no big deal. I can log in at 800x600 and then it will expand out to my larger resolution once it really matters." And as it turns out, that's just what seems to happen. Gnome fires up and sets everything up nice and pretty. Then you try out the new emacs23 package. Oh my! Where on earth did they find such huge fonts??? Why oh why does it think I need all 1152x864 pixels to see an 80 x 25 character window?

Well, it looks like this comes from the way that the vmware driver expanded out from 800x600 to 1152x864. It did it by bumping the dpi setting from 86 to 138 or something like that. (xdpyinfo | grep resolution). One of the changes between emacs22 and emacs23 was that they paid closer attention to the dpi settings as reported by X Windows so that they could make the fonts prettier. So it still thinks it's working with an 800 x 600 display and expands the window out accordingly. Yuck.

Searching for articles on how to set the dpi settings in X on Ubuntu, I find a whole bunch that say to edit /etc/X11/xorg.conf and add "Option dpi 96" or something like that to the section that says what kind of video card the system has. But there is no file at /etc/X11/xorg.conf. So searches for "Ubuntu xorg.conf missing" turn up a handful of articles that explain that XOrg is trying to make that file go away.

It seems that XOrg and Debian and Ubuntu have decided that "We don't need no stinking xorg.conf file. We can figure it all out by ourselves and don't need to bother the user with such arcane details any more." And I suppose for ordinary computers, they're probably right. But as we know, Virtual computers are only almost ordinary. They still have a few eccentricities. And apparently, one of those is that they need to be told what kind of resolution we'd really like to start out in because they can't guess very well. And the endless cacophony of articles that say to run dpkg-reconfigure -phigh xserver-xorg only frustrate because that command does absolutely nothing on Lucid other than burn a few CPU cycles any more. (See the attitude statement at the beginning of this paragraph for the reasons why.)

So this apparently harmless inability to load drivers from the vmware-config-tools.pl script wasn't as harmless as I thought it was at first glance. I wish the tools config script would ask me what resolution I would like to run in so that everything could just stay in that and not keep growing and shrinking my console window and confusing poor programs like emacs.

Anyway, I just needed somewhere to vent after spending the past two or three days trying to figure out why emacs23 is so strange when emacs22 works just fine. I guess this article burst the dam. Thank you for your listening.

Pat

0 Kudos
ZWayne
Contributor
Contributor
Jump to solution

I would like to echo Pat's sentiments as well. Ubuntu 9.10 seems very smooth compared to 10.04.

Wayne

0 Kudos
babzog
Contributor
Contributor
Jump to solution

Wow... thought I was the only one going crazy with this. I cannot believe that something as important as this would be left out soas to create such an annoying problem. In workstation 6.5 (yes, it may be fixed in ws 7 but we're not in buy mode right now so I'm stuck with what I'm stuck with), the screen starts very small and only enlarges after I log in. But... it won't enlarge until I minimize then re-click the fullscreen button in workstation.

Moreover, it's a pita - and somewhat embarassing - when trying to convince coworkers, bosses, etc of the merits of ubuntu over a very popular competitor (el chapeau) and there are issues like this. People are going to want it to "just work"... they're not gonna want to have to do a double-click tap dance every time they want their workstation to run fullscreen.

It may be nice to try and reduce user interaction - I'm all for removing choices and simplifying the process whenever it makes sense to do so - but to introduce glaring issues at the same time is just shoddy implementation. Please fix this.

0 Kudos
babystrangeloop
Enthusiast
Enthusiast
Jump to solution

the screen starts very small and only enlarges after I log in.

Welcom to grub2/Plymouth!

http://www.freedesktop.org/wiki/Software/Plymouth -- ``The idea is that early on in the boot process the native mode for the

computer is set, plymouth uses that mode, and that mode stays throughout

the entire boot process up to and after X starts. Ideally, the goal is

to get rid of all flicker during startup.''

Just forget about everything except for the new Mantra "no more flickering above all else (especially compatibility)".

The initrd contains a udev which loads the fbcon.ko from the real root file system. This is what they consider "early on in the boot process the native mode for the

computer is set" to be.

But what if fbcon does 640x480 or some small resolution? You can hack around this somehow. I've never tried but there are plenty of reports, go search for them.

But what if I don't want fbcon at all due to a weird display that it fails on? You can rebuild your initrd with fbcon aliased to a non-existent module name like "off" or "zowie".

$ cat /etc/modprobe.d/inhibit-fbcon.conf

alias fbcon off

then run:

update-initramfs -u

update-grub

Other than that I have not found a way.

0 Kudos