Installing VMware Player 4.04 on Linux Mint 13

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.

Changing from Nouveau to Nvidia Graphics Drivers on Linux Mint Debian Edition 64-bit

One way of doing this is to go to the Nvidia website and download the latest file from the relevant page on there. Then, the next stage is to restart your PC and choose rescue mode instead of the more usual graphical option. This drops you onto a command shell that is requesting your root password. Once this is done, you can move onto the next stage of the exercise. Migrate to the directory where the *.run file is located and issuing a command similar to the following:

bash NVIDIA-Linux-x86_64-295.40.run

The above was the latest file available at the time of writing so the name may have changed by the time that you read this. If the executable asks to modify your X configuration file, I believe that the best course is to let it do that. Editing it yourself or running nvidia-xconfig are alternative approaches if you so prefer.

Proprietary Nvidia drivers are included the repositories for Linux Mint Debian Edition so that may be a better course of action since you will get updates through normal system update channels. Then, the course of action is to start by issuing the following installation comands:

sudo apt-get install module-assistant
sudo apt-get install nvidia-kernel-common
sudo apt-get install nvidia-glx
sudo apt-get install kernel-source-NVIDIA
sudo apt-get install nvidia-xconfig

Once those have completed, issuing the following in turn will complete the job ahead of a reboot:

sudo m-a a-i nvidia
sudo modprobe nvidia
sudo nvidia-xconfig

If you reboot before running the above like I did, you will get a black screen with a flashing cursor instead of a full desktop because X failed to load. Then, the remedy is to reboot the machine and choose the rescue mode option, provide the root password and issue the three commands (at this point, the sudo prefix can be dropped because it’s unneeded) then. Another reboot will see order restored and the new driver in place. Running the following at that point will do a check on things as will be the general appearance of everything:

glxinfo | grep render

Synchronising package selections between Linux Mint and Linux Mint Debian Edition

To generate the package list on the GNOME version of Linux Mint, I used the Backup Tool. It simply was a matter of using the Backup Software Selection button and telling it where to put the file that it generates. Alternatively, dpkg can be used from the command line like this:

sudo dpkg --get-selections > /backup/installed-software.txt

After transferring the file to the machine with Linux Mint Debian Edition, I tried using the Backup Tool on there too. However, using the Restore Software Selection button and loading the required only produced an irrecoverable error. Therefore, I set to looking around the web and found a command line approach that did the job for me.

The first step is to load the software selection using dpkg by issuing this command (it didn’t matter that the file wasn’t made using the dpkg command though I suspect that’s what the Linux Mint Backup Tool was doing that behind the scenes):

sudo dpkg --set-selections < /backup/installed-software.txt

Then, I started dselect and chose the installation option from the menu that appeared. First time around, it fell over but trying again was enough to complete the job. Packages available to the vanilla variant of Linux Mint but not found in the LMDE repositories were overlooked as I had hoped and installation of the extra packages had no impact on system stability either.

sudo dselect

Apparently, there is an alternative to using dselect that is based on the much used apt-get command but I didn’t make use of it so cannot say more:

sudo apt-get dselect-upgrade

All that I can say is that the dpkg/dselect combination did what I wanted so I’ll keep them in mind if ever need to synchronise software selections between two Debian-based distributions in the future again. The standard edition of Linux Mint may be based on Ubuntu rather than Debian but Ubuntu is itself based on Debian so the description holds here.

A new repository for GNOME 3 Extensions

Not before time, the GNOME project has set up a central website for GNOME Shell extensions. It seems to be in the hands of extension developers to make GNOME 3 more palatable to those who find it not to their taste in its default configuration. If you are using Firefox, installation is as easy as clicking the ON/OFF icon for a particular plugin on its web page and then selecting install on the dialog box that pops up. Of all the browsers that you can use on GNOME, it seems to be Firefox that is only one that has this ability for the moment. The website may have the alpha legend on there at the moment but it works well enough so far and I have had no hesitation in using it for those extensions that are of interest to me. This is an interesting development that deserves to stay, especially when it detects that a plugin is incompatible with your version of GNOME. Currently, I use GNOME 3.2 and it pops up a useful menu for deactivating extensions when the desktop fails to load. That’s a welcome development because I have had extensions crashing GNOME 3.0 on me and running the GNOME Tweak Tool on the fallback desktop often was the only alternative. GNOME 3 seems to be growing up nicely.

Getting Gnome Shell going for Fedora 16 running in VirtualBox

There are a number of complaints out there about how hard it is to get GNOME Shell running for a Fedora 16 installation in a VirtualBox virtual machine. As with earlier versions of Fedora, preparation remains a matter of having make, gcc and kernel-devel (kernel headers, in other words). While I have got away with just those, adding dkms (dynamic kernel module support) to the list might be no bad idea either. To get all of those instated, it is a matter of running the following command as root or using sudo:

yum -y install make gcc kernel-devel dkms

The -y switch ensures that any Y/N prompts that usually appear are suppressed and that the installation is completed. Just leave it out if you are inclined to get second thoughts. Another item that has been needed with a previous release of Fedora is libgomp but I haven’t had to add this for Fedora 16 if I remember correctly.

Once those are in place, it is time to install the VirtualBox Guest Additions.  Going to Devices > Install Guest Additions… mounts a virtual CD that can be used for the installation of the various drivers that are needed. To do the installation, first go to where the installer is located using the following command:

cd /media/VBOXADDITIONS_4.1.6_74713/

Note that this location will change according to the release and build numbers of VirtualBox but the process essentially will be the same other than this. Once in there, issue the following command as root or using sudo:

./VBoxLinuxAdditions.run

Hopefully, this will complete without errors now with the precursor software that has been added beforehand. However, there is one more thing that needs doing or you will get the GNOME 3 fallback desktop instead. It pertains to SELinux, an old adversary of mine that got in the way when I was setting up a web server on a machine running Fedora. It doesn’t recognise the new VirtualBox drivers as it should so the following command needs executing as root or using sudo:

restorecon -R -v /opt

Doing this restores the SELinux contexts for the /opt directories within which the VirtualBox software directories are found. The -R switch tells it to act recursively and -v makes it verbose. When it has done its work, hopefully successfully, it is time to reboot the virtual machine and you should have a GNOME Shell desktop interface when you log in.