Do you want to connect to IPv6 Internet in a minute or so?

Well, I just learned a very quick way to connect to IPv6 Internet that really works! That is, if you have Fedora 17, but probably for other distributions it is equally easy. Here are two commands to execute that will enable IPv6 network connectivity to you personal computer:

yum -y install gogoc
systemctl start gogoc.service

First command installs package gogoc, while the second one starts it. Next time you'll need only start command. After the start command apparently nothing will happen but in a minute or so you'll have working IPv6 connection. Check it out:

# ping6 www.google.com
PING www.google.com(muc03s02-in-x13.1e100.net) 56 data bytes
64 bytes from muc03s02-in-x13.1e100.net: icmp_seq=1 ttl=54 time=54.0 ms
64 bytes from muc03s02-in-x13.1e100.net: icmp_seq=2 ttl=54 time=55.0 ms
^C
--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 54.023/54.551/55.080/0.577 ms

As you can see, Google is reachable on IPv6 addresses. You can also try traceroute6:

# traceroute6 www.google.com
traceroute to www.google.com (2a00:1450:4016:801::1011), 30 hops max, 80 byte packets
1 2001:5c0:1400:a::722 (2001:5c0:1400:a::722) 40.097 ms 42.346 ms 45.937 ms
2 ve8.ipv6.colo-rx4.eweka.nl (2001:4de0:1000:a22::1) 47.548 ms 49.498 ms 51.760 ms
3 9-1.ipv6.r2.am.hwng.net (2001:4de0:a::1) 55.613 ms 56.808 ms 60.062 ms
4 2-1.ipv6.r3.am.hwng.net (2001:4de0:1000:34::1) 62.570 ms 65.224 ms 66.864 ms
5 1-3.ipv6.r5.am.hwng.net (2001:4de0:1000:38::2) 72.339 ms 74.596 ms 77.970 ms
6 amsix-router.google.com (2001:7f8:1::a501:5169:1) 80.598 ms 38.902 ms 39.548 ms
7 2001:4860::1:0:4b3 (2001:4860::1:0:4b3) 41.833 ms 2001:4860::1:0:8 (2001:4860::1:0:8) 46.500 ms 2001:4860::1:0:4b3 (2001:4860::1:0:4b3) 48.142 ms
8 2001:4860::8:0:2db0 (2001:4860::8:0:2db0) 51.250 ms 54.204 ms 57.569 ms
9 2001:4860::8:0:3016 (2001:4860::8:0:3016) 64.727 ms 67.339 ms 69.540 ms
10 2001:4860::1:0:336d (2001:4860::1:0:336d) 80.203 ms 82.302 ms 85.290 ms
11 2001:4860:0:1::537 (2001:4860:0:1::537) 87.769 ms 91.180 ms 92.931 ms
12 2a00:1450:8000:1f::c (2a00:1450:8000:1f::c) 61.213 ms 54.156 ms 55.931 ms

It simply can not be easier that that. Using ip command you can check address you were given:

# ip -6 addr sh
1: lo: mtu 16436
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: wlan0: mtu 1500 qlen 1000
    inet6 fe80::f27b:cbff:fe9f:a33b/64 scope link
       valid_lft forever preferred_lft forever
5: tun: mtu 1280 qlen 500
    inet6 2001:5c0:1400:a::723/128 scope global
       valid_lft forever preferred_lft forever

And also routes:

# ip -6 ro sh
2001:5c0:1400:a::722 via 2001:5c0:1400:a::722 dev tun  metric 0
    cache
2001:5c0:1400:a::723 dev tun  proto kernel  metric 256  mtu 1280
2a00:1450:4008:c01::bf via 2a00:1450:4008:c01::bf dev tun  metric 0
    cache
2a00:1450:400d:803::1005 via 2a00:1450:400d:803::1005 dev tun  metric 0
    cache
2a00:1450:4013:c00::78 via 2a00:1450:4013:c00::78 dev tun  metric 0
    cache
2a03:2880:2110:cf01:face:b00c:: via 2a03:2880:2110:cf01:face:b00c:: dev tun  metric 0
    cache
2000::/3 dev tun  metric 1
unreachable fe80::/64 dev lo  proto kernel  metric 256  error -101
fe80::/64 dev vmnet1  proto kernel  metric 256
fe80::/64 dev vmnet8  proto kernel  metric 256
fe80::/64 dev wlan0  proto kernel  metric 256
fe80::/64 dev tun  proto kernel  metric 256
default dev tun  metric 1

Probably I don't have to mention that if you open Google in a Web browser you'll be using IPv6. :) In case you don't believe me, try using tcpdump (or wireshark) on tun interface.
You can stop IPv6 network by issuing the following command:

systemctl stop gogoc.service

If you try ping6 and traceroute6 commands after that, you'll receive Network unreachable messages, meaning Google servers can not be reached via their IPv6 address.

yum and fastestmirror plugin...

Few hours ago I lost my nerves because when I started yum to update my system, download was painfully slow, somewhere around 20kB/s. It is outrageous because I was using 100 Mbps link and that is probably the slowest link in the chain that ends up somewhere in GEANT. Thus, things have to be much faster than that! The best speed that can be achieved is somewhere around 50Mbps and what I was getting wasn't even remotely close to it! This wasn't something I was prepared to accept as is, so I decided to see what's happening.

Yum has a plugin, fastestmirror. The purpose of that plugin is to determine the fastest available mirror and makes yum download from it, not some random one. Usually, this plugin works very well, but this time it didn't. I tried to reset everything with

yum clean all

and than again

yum update

But it didn't help. Googling around I quickly determined that the first command didn't remove fastestmirror's data. What is necessary is to remove cache file stored in /var/cache/yum/x86_64/17/timedhosts.txt (this is location on 64-bit Fedora 17). Well, guess what, this didn't help either. Namely, fastestmirror plugin determines which mirror is the best one based on measuring how much time is necessary to establish connection with a mirror, and then it immediately disconnects. This is all OK, until mirror starts to apply some throttling effectively capping maximum speed. And this was exactly what happened to me.

It used to be possible to send SIGINT signal to yum (pressing Ctrl+C) on which yum would switch to another mirror. But this doesn't work any more. When you press Ctrl+C yum exits. Now, this is expected behavior, but the previous one was actually useful! So, there should be some way to tell yum to switch to next mirror.

In the end I solved this by looking which mirror(s) yum was using. This is printed when yum starts, e.g.:

Loading mirror speeds from cached hostfile
 * fedora: gd.tuwien.ac.at
 * fedora-debuginfo: fedora.inode.at
 * rpmfusion-free: mirrors.coreix.net
 * rpmfusion-free-debuginfo: mirrors.coreix.net
 * rpmfusion-free-updates: mirrors.coreix.net
 * rpmfusion-free-updates-debuginfo: mirrors.coreix.net
 * rpmfusion-nonfree: mirrors.coreix.net
 * rpmfusion-nonfree-debuginfo: mirrors.coreix.net
 * rpmfusion-nonfree-updates: mirrors.coreix.net
 * rpmfusion-nonfree-updates-debuginfo: mirrors.coreix.net
 * rpmfusion-nonfree-updates-testing: mirrors.coreix.net
 * rpmfusion-nonfree-updates-testing-debuginfo: rpmfusion.blizoo.mk
 * updates: gd.tuwien.ac.at
 * updates-debuginfo: fedora.intergenia.de

The problem was Fedora's main repository, which was downloaded from gd.tuwien.ac.at. So, I edited fastestmirror's configuration file /etc/yum/pluginconf.d/fastestmirror.conf and added the following line:

exclude=.at

That excluded a bit more mirrors than I intended, but it definitely solved my problem.

Fedora 17 and VMWare Workstation 9...

I just upgraded VMWare Workstation to version 9. Everything went fine except I couldn't start virtual machines. :) Each start crashed the machine with some nasty kernel error. :) A quick googling reviled this link. Basically, you have to download patch, unpack it and run installation script from within.

The only problem I had was that script, somehow, thought that it was already applied:

# ./patch-modules_3.5.0.sh
/usr/lib/vmware/modules/source/.patched found. You have already patched your sources. Exiting

What happened actually is that previous patches I applied left this file and because of some error (I didn't investigate details) the script was confused. So, I simply removed offending file (/usr/lib/vmware/modules/source/.patched) and restarted script.

Reading monitor supported resolutions...

I was browsing David Underhill's blog and this post caught my attention. Namely, in that post he explains how he had problem with a newly bought monitor that different operating systems he has set to a wrong resolution. But, the interesting thing is that there are tools in both Linux and Windows that allow you to query monitor information. The tools on Fedora are monitor-get-edid, monitor-parse-edid, and monitor-edid, all part of monitor-edid package and all written in perl. So, this is what I get running those tools on my W510:

$ monitor-get-edid | monitor-parse-edid
EISA ID: LEN40b1
EDID version: 1.3
EDID extension blocks: 0
Screen size: 34.4 cm x 19.3 cm (15.53 inches, aspect ratio 16/9 = 1.78)
Gamma: 2.2
Digital signal

    # Monitor preferred modeline (60.2 Hz vsync, 54.9 kHz hsync, ratio 16/9, 118 dpi)
    ModeLine "1600x900" 106 1600 1664 1706 1930 900 903 906 912 -hsync -vsync

    # Monitor supported modeline (50.0 Hz vsync, 45.6 kHz hsync, ratio 16/9, 118 dpi)
    ModeLine "1600x900" 106 1600 1664 1706 2324 900 903 906 912 -hsync -vsync

As it can be seen, monitor-get-edid obtains EDID information and dumps it on standard output while monitor-parse-edid reads data from standard input and produces formatted output on standard output.

Modelines produced are used to tell X server how to configure and control monitor. These were used to be defined in /etc/X11/Xorg.conf (or before that in /etc/X11/XF86Config before that). In those days the whole ingenuity of setting up graphical interface was to guess those modeline lines. Modern X Server do that automatically, so in majority of cases users don't see those. But, sometimes things don't work as expected and they have to get their hands dirty.

Ok, I tried this tool on W500, too. This is what I got:

# monitor-edid
mmap /dev/mem: Permission denied
EISA ID: IBM2887
EDID version: 1.3
EDID extension blocks: 0
Screen size: 33.1 cm x 20.7 cm (15.37 inches, aspect ratio 16/10 = 1.60)
Gamma: 2.2
Digital signal

    # Monitor preferred modeline (60.0 Hz vsync, 63.9 kHz hsync, ratio 16/10, 128 dpi)
    ModeLine "1680x1050" 120.6 1680 1712 1760 1888 1050 1051 1054 1065 -hsync -vsync

    # Monitor supported modeline (50.0 Hz vsync, 53.2 kHz hsync, ratio 16/10, 128 dpi)
    ModeLine "1680x1050" 100.53 1680 1712 1760 1888 1050 1051 1054 1065 -hsync -vsync

Note that command monitor-edid reads and parses data in one go, so it is not necessary to separately specify those commands.

I was curious so I also run those tools inside VMWare Workstation but I didn't get enything useful.

The way this information is obtained from monitor is by using I2C interface and EDID data structure. This structure can be read even if the monitor itself is turned off.

Additionally, the information about monitor can also be obtained using xrandr tool. Here is what I get on W510:

$ xrandr
Screen 0: minimum 320 x 200, current 1600 x 900, maximum 8192 x 8192
LVDS-1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
   1600x900       60.2*+   50.0 
   1152x864       60.0 
   1024x768       59.9 
   800x600        59.9 
   640x480        59.4 
   720x400        59.6 
   640x400        60.0 
   640x350        59.8 
VGA-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)

What can be seen is that currently used monitor is attached to LVDS-1 (which is laptop's integrated LCD) and that it is running with the resolution 1600x9000 and 60.2Hz refresh rate. Also are listed other supported modes. Finally, all the other connectors don't have anything connected to them.

Again, output from W510 is:

# xrandr
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192
LVDS2 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1680x1050      60.0*+   60.0     59.9     50.0
   1400x1050      60.0     59.9
   1280x1024      60.0
   1440x900       59.9     59.9
   1280x960       60.0
   1360x768       60.0
   1280x800       59.8     59.9
   1280x768       59.9     60.0
   1024x768       60.0
   800x600        60.3     56.2
   848x480        60.0
   640x480        59.9
VGA2 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)

xrandr by itself is very interesting and capable tool. For example, once it happened to me that I started a game that uses SDL which switched to a lower resolution while in full screen mode. Well, the problem was that the application didn't end regularly, but it crashed and left me with unusable resolution. I used xrandr to set correct resolution. This was the command line I used:

xrandr --output LVDS-1 --auto

Note the argument of output option. It is the one reported by xrandr without any arguments.

F17 and Python setuptools mixup...

For some time now I was having problems with Python's setuptools package. When I downloaded some package and tried to install it with the usual:

python setup.py install

I would receive the following error:

Traceback (most recent call last):
  File "setup.py", line 1, in
    from setuptools import setup, find_packages
  File "/usr/lib/python2.7/site-packages/setuptools/__init__.py", line 2, in
    from setuptools.extension import Extension, Library
  File "/usr/lib/python2.7/site-packages/setuptools/extension.py", line 5, in
    from setuptools.dist import _get_unpatched
  File "/usr/lib/python2.7/site-packages/setuptools/dist.py", line 6, in
    from setuptools.command.install import install
  File "/usr/lib/python2.7/site-packages/setuptools/command/__init__.py", line 8, in
    from setuptools.command import install_scripts
  File "/usr/lib/python2.7/site-packages/setuptools/command/install_scripts.py", line 3, in
    from pkg_resources import Distribution, PathMetadata, ensure_directory
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2755, in
    add_activation_listener(lambda dist: dist.activate())
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 704, in subscribe
    callback(dist)
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2755, in
    add_activation_listener(lambda dist: dist.activate())
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2258, in activate
    map(declare_namespace, self._get_metadata('namespace_packages.txt'))
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 1847, in declare_namespace
    _handle_ns(packageName, path_item)
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 1817, in _handle_ns
    loader.load_module(packageName); module.__path__ = path
  File "/usr/lib64/python2.7/pkgutil.py", line 246, in load_module
    mod = imp.load_module(fullname, self.file, self.filename, self.etc)
  File "/usr/lib/python2.7/site-packages/chameleon/__init__.py", line 1, in
    from .zpt.template import PageTemplate
  File "/usr/lib/python2.7/site-packages/chameleon/zpt/template.py", line 9, in
    from ..i18n import fast_translate
ImportError: cannot import name fast_translate

I already managed to solve this problem some time ago, but it reappeared and it was driving me nuts! And I forgot what I did! Googling didn't tell me a lot. So, I had to look into the code.

I had to search modules on disk, use print to see which one is actually loaded, and rpm/yum to query packages, but to cut the story short, in the end I found out that I had some dangling files and directories, probably because I did upgrade instead of clean install.The following ones were offending ones:

/usr/lib/python2.7/site-packages/chameleon/ast
/usr/lib/python2.7/site-packages/chameleon/core
/usr/lib/python2.7/site-packages/chameleon/genshi
/usr/lib/python2.7/site-packages/chameleon/i18n

This is easy to verify. Using 'rpm -qf <dir_or_file' shows for all of them (including files in those directories) that they are not owned by any package. So, I simply removed then and suddenly everything worked!

Google Chrome yum repository...

Yesterday I noticed that yum repository on Google servers with packages for Chrome doesn't work. I see this in yum output when I run update process:

google-chrome                                            |  951 B     00:00 !!!

Note that three exclamation marks at the end! Also, once I received one  other error message, but I didnt' write it down, so I don't remember exactly what it was. Anyway, checking manually URL of the repository shows that it is not available:

# lftp http://dl.google.com/linux/chrome/rpm/stable/x86_64
cd: Access failed: 404 Not Found (/linux/chrome/rpm/stable/x86_64)

But, it turns out that there is no linux repository at all:

# lftp http://dl.google.com/linux/
cd: Access failed: 404 Not Found (/linux)

I did some Googling and what puzzles me is that there is nothing about this change. I found several posts in the past that the repository isn't available, but that was over a year ago, and in the mean time repository was restored. Also, there are some more recent posts, but again, those were solved!

I checked my update logs and found that the last update was on July, 27th, so is it possible that the URL will be restored as it was in the past?

Searching for packet catpuring and interface manipulation library for Python...

I needed a script that would monitor network traffic and capture and process only DHCP traffic. It turned out I couldn't find such script so I decided to write one (more about that script in another post). For a language I decided to use Python. That was the easy part. Now, I had to decide which libraries I will use that will allow me to capture network traffic, decode DHCP request and responses, and manipulate IP addresses on interfaces.

I started with the network traffic capturing. pcap library is the library for network capture, so it was natural for me to search for a Python interface to this library. I found several such interfaces, i.e. pcap, pylibpcap, pypcap, and pcapy. There is also library interface specifically for Python 3, i.e. py3kcap. While searching for pcap interface, three other Python libraries poped out: libdnet (here is the old project page), dpkt and scapy.

But, not all libraries are equal, nor they serve the same purpose. libdnet allows sending packets, manipulation with kernel's routing tables, firewall and arp cache. So, besides Ethernet and IP, it doesn't offer much more in term of supported protocols. dpkt, on the other hand, is made just for this purpose! It supports easy creation and parsing of different TCP/IP protocols. Finally, Scapy is a swiss army knife of network manipulation. It offers shell in which one can manipulate packets, but also can be used within other scripts. Unfortunately, while browsing the source of Scapy I realized that it uses os.popen interface and calls external programs. So, this actually was enough for me to eliminate scapy from further consideration.

The next elimination criteria is availability of the packages within CentOS and Fedora. I try to hold on prepackaged software as much as possible, so quick search (yum search) showed that on both, CentOS 6 and Fedora 17, there are packages for pcapy and dpkt (named python-dpkt). For some reason, there is dnet, but python interface isn't packaged. I found this bugzilla entry, but without any answer!

So, I settled on pcapy and dpkt. The only piece of puzzle that was missing now is how to manipulate interface addresses. I stumbled on netifaces, which allows me to obtain information about interfaces and also on this post for Windows. But all the results I got were on how to obtain IP address. In the end, I gave up and decided that I'll try to use libdnet even though I'll have to compile it from the source. Either that, or I'll use raw sockets and ioctls which are accessible from Python using standard libraries.

And for the end, as a curiosity, I'll mention that there is Python interface to IPTables, python-iptables, which is also packaged for Fedora.

Upgrade to Fedora 17...

I upgraded to Fedora 17 using preupgrade tool few days ago. This is writeup with experiences of that process. Maybe it helps someone out there... :)

As I didn't want to reinstall everything from scratch, I decided to use preupgrade tool. Additional benefit of this tool is that it first downloads all the necessary packages and then start the upgrade proces. So, I started preupgrade in a mid of the day and it started to download all the necessary packages. Then, it asked me to reboot machine in order for upgrade to start. Since there were over 6000 packages to upgrade I decided to start the upgrade process in the evening when I' going to sleep so that the next morning the laptop is ready for use. Thus, I declined upgrade at that moment and continued to work as normal.

In the evening I started again preupgrade tool. This time, for some unknown reason, it complained because of third party repositories I'm using (more specifically, because of rpmfusion). So, I disabled all but Fedora's repositories and restarted preupgrade. Well, it went almost without any problem. The only thing that happened is that installer stuck somewhere around 1/3rd of the installation process and I only discovered it when I woke in the morning. After reboot it continued as if nothing happened so the only consequence was that I had to wait in the morning for it to finish. Otherwise, everything was OK.

Next, I decided to recompile OMNeT++ since I'm using it for some simulations. I'm using the newest version, 4.2.2. There was a minor problem because of newer gcc (it is 4.7.0) but quick googling gave solution immediately. It could be that if you are using some older version you'll have much more problems because of changes in the C++ compiler shipped with Fedora.

Then, I started yum in order to see what new gnome-shell plugins are available. As I started installation of one plugins, after the installation finished, yum showed a lot of errors like the following ones:

389-ds-base-libs-1.2.11.1-1.fc17.x86_64 is a duplicate with 389-ds-base-libs-1.2.10.6-1.fc16.x86_64

ConsoleKit-0.4.5-2.fc17.x86_64 has installed conflicts filesystem < ('0', '3', None): filesystem-2.4.44-1.fc16.x86_64

Obviously, something went wrong with preupgrade process. So, first I tried package-cleanup tool, but without any success. It wanted to remove packages, which a) isn't what I wanted, and b) it didn't managed to remove them anyway. Then, I tried recipe from this link. That one didn't work either. So, I ended up manually removing packages with yum and then installing them again. This took me several hours, not the best way to spend your time.

Finally, after solving that problem everything else seems to work. There is one thing that annoys me. gnomines is very slow to react on clicks. At the initial opening it takes 1 or 2 seconds to start, and after each click there is a noticeable delay. I don't know what causes it, but I certainly do hope that they will fix it soon. :)

Update 1 [20120605]
Ok, there is one additional issue I found out. But this one occurs every time I install new version of Fedora, so I already know what to do. :) Namely, if you are on a network where domain name ends in .local (e.g. server.local.) then DNS is not invoked but mdns4 is used. This is manifested in a way that those servers are inaccessible with a message Server not found, or something similar. Anyway, the root cause is in the file /etc/nsswitch.conf, i.e. the line that defines how host names are resolved is set to:

hosts:      files mdns4_minimal [NOTFOUND=return] dns myhostname

you should remove mdns4_minimal and the content within square brackets, so it should look like this:

hosts:      files dns myhostname

And that's it!

Update 2 [20120614]
Well, it seems that VMWare Workstation isn't working with a new Fedora. I'm using kernel 3.4.0-1.fc17.x86_64. Anyway, when I start vmware, it tells me that it has to configure vmware and then, during build process, the following error while building blocking FS appears:

make: Entering directory `/tmp/vmware-root/modules/vmblock-only'
make -C /lib/modules/3.4.0-1.fc17.x86_64/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/kernels/3.4.0-1.fc17.x86_64'
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/dbllnklst.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/file.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/block.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/inode.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/super.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/control.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/filesystem.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/module.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/stubs.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/dentry.o
/tmp/vmware-root/modules/vmblock-only/linux/filesystem.c: In function ‘FsOpReadSuper’:
/tmp/vmware-root/modules/vmblock-only/linux/filesystem.c:528:4: error: implicit declaration of function ‘d_alloc_root’ [-Werror=implicit-function-declaration]
/tmp/vmware-root/modules/vmblock-only/linux/filesystem.c:528:15: warning: assignment makes pointer from integer without a cast [enabled by default]
cc1: some warnings being treated as errors
make[2]: *** [/tmp/vmware-root/modules/vmblock-only/linux/filesystem.o] Error 1
make[1]: *** [_module_/tmp/vmware-root/modules/vmblock-only] Error 2
make[1]: Leaving directory `/usr/src/kernels/3.4.0-1.fc17.x86_64'
make: *** [vmblock.ko] Error 2
make: Leaving directory `/tmp/vmware-root/modules/vmblock-only'

The solution for this I found here. Basically, the function d_alloc_root has been renamed to d_make_root and that search/replace operation should be done within the archive vmblock.tar (in /usr/lib/vmware/modules/source/). Actually, there is only one occurence of d_make_root in file linux/filesystem.c.

Update 3 [20120822]
I had problem with Python setuptools because of upgrade. See here for details.