Technology Tales

Adventures & experiences in contemporary technology

Installing VMware Player 4.04 on Linux Mint 13

15th July 2012

Curiosity about the Release Preview of Windows 8 saw me running into bother when trying to see what it’s like in a VirtualBox VM. While doing some investigations on the web, I saw VMware Player being suggested as an alternative. Before discovering VirtualBox, I did have a licence for VMware Workstation and was interested in seeing what Player would have to offer. The, it was limited to running virtual machines that were created using Workstation. Now, it can create and manage them itself and without any need to pay for the tool either. Registration on VMware’s website is a must for downloading it though but that’s no monetary cost.

One I had downloaded Player from the website, I needed to install it on my machine. There are Linux and Windows versions and it was the former that I needed and there are 32-bit and 64-bit variants so you need to know what your system is running. With the file downloaded, you need to set it as executable and the following command should do the trick once you are in the right directory:

chmod +x VMware-Player-4.0.4-744019.i386.bundle

Then, it needs execution as a superuser. With sudo access for my user account, it was a matter of issuing the following command and working through the installation screens to instate the Player software on the system:

sudo ./VMware-Player-4.0.4-744019.i386.bundle

Those screens proved easy for me to follow so life would have been good if that were all that was needed to get Player working on my PC. Having Linux Mint 13 means that the kernel is of the 3,2 stock and that means using a patch to finish off the Player installation because the required VMware kernel modules seem to silently fail to compile during the installation process. This only manifests itself when you attempt to start Player afterwards to find a module installation screen appear. That wouldn’t be an issue of itself were it not for the compilation failure of the vmnet module and subsequent inability to start VMware services on the machine. There is a prompt to peer into the log file for the operation and that is a little uninformative for the non-specialist.

Rummaging around the web brought me to the requisite patch and it will work for Player 4.0.3 and Workstation 8.0.2 by default. Doing some tweaking allowed me to make it work for Player 4.04 too. My first step was to extract the contents of the tarball to /tmp where I could edit patch-modules_3.2.0.sh. Line 8 was changed to the following:

plreqver=4.0.4

With the amendment saved, it was time to execute the shell script as a superuser having made it executable before hand. This can be accomplished using the following command:

chmod +x patch-modules_3.2.0.sh && sudo ./patch-modules_3.2.0.sh

With that completed successfully, VMware Player ran as it should. An installation of Windows 8 into a new VM ran very smoothly and I was impressed with performance and responsiveness of the operating system within a Player VM. There are a few caveats though. First, it doesn’t run at all well with VMware Tools so it’s best to leave them uninstalled and it doesn’t seem to need them either; it was possible to set the resolution to the same as my screen and use the CTRL+ALT+ENTER shortcut to drop in and out of full screen mode anyway. Second, the unattended Windows installation wasn’t the way forward for setting up the VM but it was no big deal to have that experiment thwarted. The feature remains an interesting one though.

With Windows 8 running so well in Player, I was reminded of the sluggish nature of my Windows 7 VM and an issue with a Fedora 17 one too. The result was that I migrated the Windows 7 VM from VirtualBox to VMware and all is so much more responsive. Getting it there took not a little tinkering so that’s a story for another entry. On the basis of my experiences so far, I reckon that VMware Player will remain useful to me for a little while yet. Resolving the installation difficulty was worth that extra effort.

Getting VirtualBox working on Ubuntu after a kernel upgrade

27th July 2008

In previous posts, I have talked about getting VMware Workstation back on its feet again after a kernel upgrade. It also seems that VirtualBox is prone to the same sort of affliction. However, while VMware Workstation fails to start at all, VirtualBox at least starts itself even if it cannot get a virtual machine going and generates errors instead.

My usual course of action is to fire up Synaptic and install the drivers for the relevant kernel. Looking for virtualbox-ose-modules-[kernel version and type] and installing that usually resolves the problem. For example, at the time of writing, the latest file available for my system would be virtualbox-ose-modules-2.6.24-19-generic.  If you are a command line fan, the command for this would be:

sudo apt-get install virtualbox-ose-modules-2.6.24-19-generic

The next thing to do would be to issue the command to start the vboxdrv service and you’d be all set:

sudo /etc/init.d/vboxdrv start

There is one point of weakness (an Achilles heal, if you like) with all of this: the relevant modules need to be available in the first place and I hit a glitch after updating the kernel to 2.6.24-20 when they weren’t; I do wonder why Canonical fail to keep both in step with one another and why the new kernel modules don’t come through the updates automatically either. However, there is a way around this too. That means installing virtualbox-ose-source via either Synaptic or the command line:

sudo apt-get install virtualbox-ose-source

The subsequent steps involve issuing more commands to perform a reinstallation from the source code:

sudo m-a prepare

sudo m-a auto-install virtualbox-ose

Once these are complete, the next is to start the vbox drv as described earlier and to add yourself to vboxusers group if you’re still having trouble:

sudo adduser [your username] vboxusers

The source code installation option certainly got me up and running again and I’ll be keeping it on hand for use should the situation raise its head again.

A first look at Ubuntu 8.10

20th July 2008

I must admit that my curiosity got the better of me when screenshots of Ubuntu’s 8.10, otherwise known as Intrepid Ibex, started to make their appearance. It is only at alpha2 stage so it’s definitely a no-no for production systems. However, it does run surprisingly smoothly even at this stage. Yes, I have seen rough edges and the biggest of them all has made me install it onto my spare PC; there is certainly tendency for systems to hang when you try running 8.10 in virtual machines, my preferred method for these kinds of explorations. Try it in VirtualBox and kernel panic messages ensue while you can log in on VMware Workstation only for the desktop never to load. Those could be major deficiencies for some but they have both been reported with the former being seen by many and the latter being flagged by my own self.

Because I was using a version with the alternate installer, the usual slickness that we expect of Ubuntu installations wasn’t apparent. I am sure that will change in time for the final release but I didn’t find it too taxing to get things going with this means. Nevertheless, I reckon that we will see the usual feel return in later development versions and very much in time for the final release. Because I was installing over the top of a previous Ubuntu installation, I didn’t want to lose everything but I needed to leave it wipe out the previous root system partition for it to continue without freezing. Because my home area is on a separate partition, there was no problem and it picked up settings like desktop backgrounds without a fuss. One thing that might annoy some is that all this takes manual intervention; you don’t get the sort of non-destructive and seamless upgrade capability that openSUSE 11 gives.

What you get when the installation is completed is a Linux desktop that won’t look too different from what we are used to using. Of course, we get the New Human theme with its tasteful chocolate tones in place of the previous default orangey browns. They need to sort out a bug (another of my reports)  where black text is being displayed on dark backgrounds on the default display of drop down menus in Firefox and maybe look into why changing the level of enhancements from Compiz Fusion messes up the display of the workspace switcher in the task bar but it’s fine apart from this.

Otherwise, it’s a case of steady as she goes with OpenOffice 2.4, Firefox 3 and so on. That may change as time goes on OpenOffice 3 looming in the horizon. For some, all this continuity is all well and good but I could foresee comments front some parts that nothing dramatic is happening and that Ubuntu cannot afford to stand still with the advances of Fedora, openSUSE, Mandriva and so on. Saying that, I personally like the continuity because it doesn’t mean that my apple cart is going to get overthrown now and again. Indeed, you could say that the whole Linux distribution market has matured very nicely with evolution being the order of the day and I suppose that Ubuntu needs to be seen to be evolving more than perhaps it has been doing.

In summary, it’s early days for Intrepid Ibex but it works well even at this stage. In fact, it is running sufficiently so that I am writing this very post in a Firefox session running on the thing.  It’ll be interesting to see how it goes from here and if any more pleasant surprises are visited upon us. After the “safety first” approach of Hardy Heron, I suppose that Canonical can feel a little more adventurous so we’ll see what comes. In the meantime, Here are a few screenshots below for your perusal:

Disk corruption can be virtual too

16th July 2008

It’s the sort of sight that causes you to fear the worst, an unchanging black screen with a flashing cursor. That was what started greet me in recent days when I tried to fire up a Windows XP guest in VMware Workstation. The cause was the corruption of a virtual disk, an ominous thing that affected a supplemental virtual hard drive that I had added to the virtual machine rather than its main one. There might have been some data on there but it was nothing that I didn’t have elsewhere anyway. Removing the broken disk from the XP VM returned the situation to fuller health and I simply tried creating a new one again. So far, this seems to be working fine but I’ll be keeping a watchful eye on things.

I have no idea why the corruption happened but the broken disk files were created without a VMDK extension so that might indicate that something was amiss with the process that created them. It would be better if VMware highlighted the state of its virtual disks but it was when I tried opening the trashed disk with VirtualBox that a warning was given and VMware did the same when I tried I tried it with that afterwards (opening VMware virtual disks with VirtualBox is possible but you need to ensure that no attempt at importation is made or you could end up with a breakage). I may have discovered the fault in a roundabout manner but it’s better to know what’s gone wrong than not to know at all.

Killing those runaway processes that refuse to die

5th July 2008

I must admit that there have been times when I logged off from my main Ubuntu box at home to dispatch a runaway process that I couldn’t kill and then log back in again. The standard signal being sent to the process by the very useful kill command just wasn’t sending the nefarious CPU-eating nuisance the right kind of signal. Thankfully, there is a way to control the signal being sent and there is one that does what’s needed:

kill -9 [ID of nuisance process]

For Linux users, there seems to be another option for terminating process that doesn’t need the ps and grep command combination: it’s killall. Generally, killall terminates all processes and its own has no immunity to its quest. Hence, it’s an administrator only tool with a very definite and perhaps rarely required use. The Linux variant is more useful because it also will terminate all instances of a named process at a stroke and has the same signal control as the kill command. It is used as follows:

killall -9 nuisanceprocess

I’ll certainly be continuing to use both of the above; it seems that Wine needs termination like this at times and VMware Workstation lapsed into the same sort of antisocial behaviour while running a VM running a development version of Ubuntu’s Intrepid Ibex (or 8.10, if you prefer). Anything that keeps you from constantly needing to restart Linux sessions on your PC has to be good.

VirtualBox OSE and 64 bit Guest Operating Systems

17th May 2008

I have gone and downloaded the next to four gigabytes of the 64 bit variant of Fedora 9 using Bittorrent and so thought that it might be a good idea to set the thing up in a VirtualBox virtual machine. However, that stratagem got scuppered by VirtualBox’s not supporting 64 bit operating systems. I do have VMware Workstation and, since that supports what I was doing, I resolved to set up Fedora there. After my plan’s getting shelved, my trying out VirtualBox is a matter that remains outstanding…

VMware Workstation in full screen mode hobbles my keyboard

14th May 2008

I have recently encountered an odd situation following my recent upgrade to Ubuntu 8.04: when I use VMware Workstation to run Windows XP in full screen mode, the keyboard no longer acts as it should. For instance, Caps Lock and Num Lock keys stop working as does the Shift key. Logging out and back in again is the least that’s needed to set things right but there has to be a better way to fix the problem. I am not saying that it’s limited to the scenario where I saw it happen but it’s still very odd behaviour. If you have a solution, please let me know. Of course, I’ll keep you posted if I find one. In the meantime, I’ll be avoiding full screen mode with VMware as much as I can.

Update 1:

I have done a spot of digging on this one since and gained the impression that there might be a conflict between VMware and the version of X.org Server that comes with Ubuntu. A restorative trick that I have seen suggested is to issue the following command in a terminal, replacing "gb" with your own locale, but I have yet to see if it works:

setxkbmap -rules xorg -layout "gb"

In any case, it looks as if it is not a permanent fix but just a way to keep working without resorting to system restarts, logging off and back on, etc.

Update 2:

I can now verify that the comand quoted above works for me. Of course, it would better to find a permanent fix and even better for the behaviour never to occur at all but any fix is better than none whatsoever.

Do I still need serial numbers?

19th November 2007

My spot of bad luck with Windows in August highlighted the importance of hanging on to serial numbers for software that I had purchased over the internet and downloaded. I could at the ones that I needed but they were retained in a motley mix of text files and emails; one even was rediscovered by pottering back to the website of the purveyor. The security of the installation files themselves was another matter of some concern but I was rather more organised in that regard. Both of these are things that need checking before Windows falls to pieces on you and needs to be reinstalled. Of course, human nature being what it is means that we often end up picking up the pieces after a calamity has struck when a spot of planning would have made things that bit easier.

Linux does make life easier on this front: commercial applications are anything but the dominant force that they are in the world of Windows. That means that serial numbers are few and far between and I only need the one for VMware Workstation. The mention of VMware brings me to my retention of Windows so knowing where serial numbers are located remains a good idea. Even so, I cloned my Windows VM so that any Windows restoration following a destructive crash should be a quicker affair. Now that I am a Linux user, Windows crashes should not encroach as much on my home computing any more and Linux should be more stable anyway…

Setting up openSUSE in VMware Workstation

12th November 2007

It should have been as straightforward as following the instructions on the openSUSE website but a bug in VMware Tools derailed things on me. The usual procedure would have you starting by selecting Install VMware Tools from the VM menu before popping into the virtual machine to do the rest. Once binutils, gcc, gcc-c++, kernel-source and make are in place, next steps should involve using YaST to install the RPM for you to run the vmware-config-tools.pl script from the terminal.

However, a bug in compat_slab.h puts a stop to any hopes of installing the vmhgfs component. That’s needed if you want to enable the shared folders feature; looking in /mnt/hgfs then would get you to any shared folders Everything else will be there but why miss out on one piece of functionality when it come in useful?

Having found a useful thread on the subject, here’s my way forward: it is as the expected procedure up to the point of installing the RPM. With VMware Tool installation on a Linux guest, you have two options: use RPM as described or use the compressed tarball. The latter seems the better course. Extract the contents into a folder and navigate to that folder. When there go into vmware-tools-distrib/lib/modules/source and extract the file vmhgfs.tar. Proceed into the resulting vmhgfs-only contained wherever you put it and perform the following edit of compat_slab.h:

Change

#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 22) || defined(VMW_KMEMCR_HAS_DTOR)

to

#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 22) || defined(VMW_KMEMCR_HAS_DTOR)

After that, recreate and replace vmhgfs.tar before issuing the following command in the terminal window while in the vmware-tools-distrib directory: ./vmware-config-tools.pl (anything prefixed with "./" picks up the file from the current working directory rather than where system binaries are stored). A kernel compilation will be involved but all of the defaults should be sensible. Hopefully, all will work well after this.

Update: I am left with a number of outstanding issues that I need to resolve. Lack of internet access from the VM is one of them and a constant forgetfulness regarding the nationality of my keyboard (it’s British) might be another. In the interim, I have removed VMware tools until I can spend some time setting these to rights. Internet access has returned and British keyboard layout is being interpreted correctly in the meantime…

Turning the world on its head: running VMware on Ubuntu

2nd November 2007

When Windows XP was my base operating system, I used VMware Workstation to peer into the worlds of Windows 2000, Solaris and various flavours of Linux, including Ubuntu. Now that I am using Ubuntu instead of what became a very flaky XP instance, VMware is still with me and I am using it to keep a foot in the Windows universe. In fact, I have Windows 2000 and Windows XP virtual machines available to me and they should supply my Windows needs.

A evaluation version of Workstation 6 is what I am using to power them and I must admit that I am likely to purchase a license before the evaluation period expires. Installation turned out to be a relatively simple affair, starting with my downloading a compressed tarball from the VMware website. The next steps were to decompress the tarball (Ubuntu has an excellent tool, replete with a GUI, for this) and run vmware-install.pl. I didn’t change any of the defaults and everything was set up without a bother.

In use, a few things have come to light. The first is that virtual machines must be stored on drives formatted with EXt3 or some other native Linux file system rather than on NTFS. Do the latter and you get memory errors when you try starting a virtual machine; I know that I did and that every attempt resulted in failure. After a spot of backing up files, I converted one of my SATA drives from NTFS to Ext3. For sake of safety, I also mounted it as my home directory; the instructions on Ubuntu Unleashed turned out to be invaluable for this. I moved my Windows 2000 VM over and it worked perfectly.

Next on the list was a serious of peculiar errors that cam to light when I was attempting to install Windows XP in a VM created for it. VMware was complaining about a CPU not being to run fast enough; 2 MHz was being stated for an Athlon 64 3000+ chip running at 1,58 GHz! Clearly, something was getting confused. Also, my XP installation came to a halt with a BSOD stating that a driver had gone into a loop with Framebuf fingered as the suspect. I was seeing two symptoms of the same problem and its remedy was unclear. A message on a web forum put the idea of rebooting Ubuntu into my head and that resolved the problem. I’ll be keeping an eye on it, though.

Otherwise, everything  seems to be going well with this approach and that’s an encouraging sign. It looks as my current Linux-based set up is one with which I am going to stay. This week has been an interesting one already and I have no doubt that I’ll continue to learn more as time goes on.

  • All the views that you find expressed on here in postings and articles are mine alone and not those of any organisation with which I have any association, through work or otherwise. As regards editorial policy, whatever appears here is entirely of my own choice and not that of any other person or organisation.

  • Please note that everything you find here is copyrighted material. The content may be available to read without charge and without advertising but it is not to be reproduced without attribution. As it happens, a number of the images are sourced from stock libraries like iStockPhoto so they certainly are not for abstraction.

  • With regards to any comments left on the site, I expect them to be civil in tone of voice and reserve the right to reject any that are either inappropriate or irrelevant. Comment review is subject to automated processing as well as manual inspection but whatever is said is the sole responsibility of the individual contributor.