[Debian] How to fix "Gnome 3 failed to load" running Debian in VMware

By +theblazingangel
in HOW TO & FAQ Guides

 Share

Recommended Posts

Grand Master

+theblazingangel MVC

Posted
  • MVC
Posted

Playing around recently with a copy of Debian 7.5 in VMware it took me a while to realise that the desktop environment I was experiencing was in fact Gnome 2 (aka classic mode), not Gnome 3; it didn't help that I'd actually installed a couple months prior and not noticed / lost the "Gnome 3 failed to load" error message. Looking for a solution to get Gnome 3 running I eventually stumbled upon this solution which helpfully explained the cause of the problem and guided me through fixing it. The instructions there are a little out of date now, so I thought I'd provide a more up to date set for anyone struggling with this.
 
Firstly, what is the cause of the problem? Well, as explained in the above link and elsewhere, the new Gnome 3 desktop environment requires 3D hardware acceleration and if not available, it falls back to classic mode; the graphics driver provided in the current Debian stable release (7.x - Wheezy) for use with VMware has such 3D hardware acceleration but it seems to have been disabled when the driver was compiled. Below I will walk you through an updated set of instructions to obtain a copy of the driver source code, compile it with hardware acceleration enabled and finally install it. I'll skip over the 'vmware tools installation' portion of the instructions found at the above link though, I believe that these tools are only required to enable interaction between host OS and virtual machine OS such as copy/paste, which I had no interest in and is irrelevant to fixing the issue at hand.
 
A secondary requirement is that 3D graphics acceleration is enabled in the hardware configuration settings of the VMware virtual machine itself. To check, from the VMware VM selection/management window, select the virtual machine and click on 'Edit virtual machine settings', select the 'display' entry, and check if 'Accelerate 3D graphics' is enabled. Alternatively, from a running VM, from the VMware toolbar, on the 'player' menu, go to 'Manage' then 'Virtual Machine Settings', then continue as just described, however you will not be able to actually modify the setting while the VM is running.
 
Before I begin explaining how to fix the driver issue I'd like to point out that, as I experienced on a fresh install, if you happen to switch your installation from Debian 'stable' to 'testing' or 'unstable', you will have absolutely no need to follow these instructions because the updated packages available from them are already suitable for providing 3D hardware acceleration, all you need is the option checked in the VM setting as just described.
 
So, on with the instructions...
 
* Note, you will need an internet connection available for this!
 
1) Open a terminal and become root
 
You can become root by entering the following command and then providing your sudo password when prompted:

sudo -i

 
Alternatively you can use the su command if you've got a root account enabled; open a root terminal, or prepend the sudo command to some or all of the below commands
 
2) You'll need some additional packages to prepare for compiling the new driver(s)

apt-get install autoconf libtool xutils-dev xorg-dev flex bison  libx11-xcb-dev libxcb-glx0-dev g++ git
apt-get install libxcb-dri2-0-dev libxcb-xfixes0 libxcb-xfixes0-dev llvm libxml2 libxml2-dev python-libxml2 build-essential
apt-get build-dep mesa

 
The packages listed here are identical to those listed in the original instructions I'm basing this on, I haven't scrutinised it, it just worked for me as is. However, I did discover in the course of using the original instructions that the latest copies of the source code (which we'll get to shortly) were using dri3 not dri2 - notice that there's a package named libxcb-dri2-0-dev in the second set above - so if you're using the latest code you may find that you need to get the libxcb-dri3-0-dev.
 
3) Let's create a new directory to work in

mkdir vmware-3d
cd vmware-3d

 
4) Now you need to get a copy of the drm, mesa and xf86-video-vmware source code.
 
* note, 'drm' here is short for direct rendering manager, nothing to do with digital rights management!
 

git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-vmware
git clone git://anongit.freedesktop.org/mesa/mesa
git clone git://anongit.freedesktop.org/git/mesa/drm

 
git will create a directory within your 'vmware-3d' directory for each of them, 'xf86-video-vmware', 'mesa' and 'drm' respectively.
 
When I did this, the third one failed several times with 'connection refused' (if I remember the error correctly), it worked perfectly a few minutes later however, so just keep trying if it fails.
 
Now it's from this point forward that I'm going to make some significant changes to the original instructions because as they were, they didn't work for me, I got errors. Why did they apparently work for the original author and not me? Because the commands above have gotten you a copy of the very latest source code, including work being done for the next versions of these packages. You have not got the same copy of the source code that the author of the original instructions got; the copies I got produced errors when I tried to compile them and you may experience the same. So you need to do something about that, and here comes the git utility to the rescue!
 
5) Try to understand some very basic concepts of git (somewhat optional, skip if you're already familiar with it)
 
It may help you get through step 6 below if you can get a basic understanding of git. I'll try to keep this as simple as I can.
 
git is a powerful source code management tool. Essentially, when you used git to obtain a copy of the source code with the git 'clone' command above, you haven't simply obtained a copy of the latest code, you've also obtained a copy of a database of save point data (aka "commits") which tracks the changes the developer has been making to the source code files over time (note, new save points are created manually by the developer - a git command is run, which assesses and captures in the database any differences in the files since the previous save point). The code and the database are referred to as a "git repository". With the use of git commands, you can go back in time to previous save points, such as points where the developer released a new version to users. This is what we need to do - take the source code back in time, avoiding save points that result in errors when we try to compile and install!
 
There's one further thing you need to understand with git and that's 'branching'. Let's say a developer wants to experiment with some new big change to the code, something that will take some time to complete, but they can't or don't want to stop also separately working on other improvements to the existing code at the same time. This developer could make a copy of the source code files and git database into a separate directory and work on them as somewhat separate projects (aka "branches"), then later either throw away the experiment, or if keeping the change, manually merging the changes made in each of the two separate code branches together. A better approach is to use the powerful branching feature built into git. With simple git commands you can create new branches, which are kept track of in the git database; switch between them to change which branch's source code files are currently present in the directory for this project; and even often automatically merge branches into one another, though sometimes manual effort may be required.
 
You can read more about git here if you wish.
 
Note:

  • The 'master' branch is the primary branch of any project
  • All save points ("commits") must have a description, which may be useful to get a brief understanding of what was changed.
  • Commits can have "tags" attached to them.

Product versioning may be handled like so:

  • Developers may need to keep the code for different major versions of their product in separate branches, allowing bugfixes and such to previous major versions which are still being maintained to be done separately from each other and from the continuing work improving the existing latest major version, or working on the next one that's under development, which is being done in the master branch.
  • This can be seen with the 'mesa' packages we've obtained source code for; development work for version 10.3 is being done in the master branch, and separate branches exist for versions 10.2, 10.1, 10.0, etc.
  • At certain points in the development under these version branches, copies of the product will be released to users with a version number attached. The commit at which point a release is made can be tagged with the version number the release was made with, allowing easy identification in the list of commits at which releases are made and making it easy to take the code back in time as described above to the right point to be able to obtain the code for a particular version of a product.
  • You can see this with the mesa package, for example under the 10.1 branch, commit tags marking the release points of 10.1.5, 10.1.4, etc. Commits at the top of the list, (if the very first is not tagged with a version number), are changes that will go into the next release when the developer is ready.

To do anything with a git repository such as switching branches, first, in the terminal, you must navigate with the cd command to the the directory containing the repository to make it the terminal's working directory. Now you can issue git commands and git will operate on that repository.
 
Refer to the online manual to learn how to use git (not necessary to complete this, I'll walk you through the commands you need below).
 
6) Compile and install the code for the three source code packages downloaded
 
Note, the order in which the below packages are compiled and installed I believe is important!
 
To help determine which version to switch to for each of them, you can browse the branches, tags, commits, etc of the three packages we have obtained source code for here:

 

WARNING: If compilation of a package as done below fails, you need to understand the following: The compilation commands will result in modifications to the set of files currently in the working directory (e.g. new files created). If you try to switch to a different branch (because in this case you want to try compiling a different one), I believe that git may try to merge the unsaved changes into the new set of files you've checked out. This could obviously mess things up. I know I started experiencing issues when trying to find a version of mesa that would compile for me; I noticed that the errors I received on one particular version changed when I retried it later after trying others which was strange, but understandable if this merging of unsaved changes is happening. I'm not as familiar with git as I'd like to be. I believe that the correct solution would have been to do a cleanup to throw away unsaved changes prior to switching branches, which apparently can be done with the command below (in my case I ended up deleting the repositories and re-cloning them and a particular version then compiled for me which I stuck with if I remember correctly, I was only playing around wanting to see what Gnome 3 was like at the time, so getting the latest version possible wasn't a priority):
 

git clean -df & git checkout .

Don't miss the full stop on the end!
 
6a) Building and installing the drm package
 
I'll break the instructions into pieces for this one (some people may need baby steps tongue.png )
 
Navigate into the repository's directory:
 

cd drm

 
The latest copy of the code worked fine for me on this package. If you're happy to go with it, you can skip this next bit. However, if you want to get the latest code released under an actual version number, not simply the very latest development copy of the code, then it looks like the master branch is the one to go for on this package, and 2.4.54 is the latest version at the time of writing this (as you can see here). You can get this simply as follows:
 

git checkout tags/libdrm-2.4.54

 
Next, compile and install. It could fail at any point here, watch out for errors, if one occurs, you may need to then run the cleanup command mentioned above, switch to a different code version and then try these again!

./autogen.sh
./configure --enable-vmwgfx
make
make install

 
Note, I had to replace "--enable-vmwgfx-experimental-api" in the original instructions with "--enable-vmwgfx" for it to work on this newer code.
 
Finally, navigate out of this directory ready to navigate into the one for the next package.
 

cd ..

 
I'll post the code for the next two packages all in one lump, hoping you'll be able to follow what's being done and understanding for yourself what the appropriate actions to take are if it fails at any point.
 
6b) Building and installing the mesa package
 
I believe the version of mesa that worked for me was 8.0.5 from the 8.0 branch. Feel free to experiment with others though; failing to clean up my changes to the repository on a failed compile before switching to and trying a different version may have lead to a bunch of errors that I may not have experienced otherwise, and after starting afresh I don't remember if I tried some the newer ones again (and since moved to Debian testing/unstable where you don't need to do any of this).
 
So here first I'll switch to the 8.0 branch, then checkout the latest version with the tag (currently 8.0.5). Not sure if two steps are actually necessary, but can't hurt.
 
You can get the full name of the branch via the following command

git branch -a

 
Note that it's not quite the same as that shown in the link posted above, it now has 'remotes/origin/' on the front. The tag is the same as seen via the link posted above.
 

cd mesa
git checkout remotes/origin/8.0
git checkout tags/mesa-8.0.5
./autogen.sh
./configure --prefix=/usr --enable-xa --with-gallium-drivers=svga --with-dri-drivers= --disable-egl --disable-glu --disable-glw
make
make install
cd ..

 
I believe you can ignore any warnings about the latter of those flags on the configure line not being recognised.
 
Don't forget, near the beginning of this that I said that newer versions use dri3, so you might need to get a certain package to replace the dri2 one if this is to compile and install if you're trying to use a newer mesa version, you'll see and error about it where applicable.
 
6c) Building and installing the xf86-video-vmware package
 
Again, I think the master branch is best for this package. The latest version tagged commit currently is 13.0.2. If I remember correctly, trying to compile with the latest development commit gave me errors when I tried it, so best to fall back to the latest version tagged one, which is what worked for me.
 

cd xf86-video-vmware
git checkout tags/xf86-video-vmware-13.0.2
./autogen.sh
./configure --prefix=/usr
make
make install

 
7) Reboot
 
You'll need to reboot for the change to take effect, fingers crossed it worked! (If not, let me know).

  • 3 months later...
This topic is now closed to further replies.
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.