Fedora 25, kernel 4.9 and VMWare Workstation 12.5.2

Well, after upgrading Fedora 25 which included kernel 4.9.5, VMWare Workstation stopped working again! The fix is easy, even though it annoying to constantly have to patch something in VMWare. Anyway, the procedure - taken from here - is:

1. Switch to root account.
2. Go to /usr/lib/vmware/modules/source.
3. Make backup of files vmmon.tar and vmnet.tar.
4. Unpack those files using 'tar xf' command.
5. Patch file vmnet-only/user_if.c, i.e. you have to open it in you favorite text editor and in function UserifLockPage() that's around line 113 change the following part:
   

   #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 6, 0)
       retval = get_user_pages(addr, 1, 1, 0, &page, NULL);
   #else
       retval = get_user_pages(current, current->mm, addr,
                   1, 1, 0, &page, NULL);
   #endif

   with the following:
   

   #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 9, 0)
        retval = get_user_pages(addr, 1, 0, &page, NULL);
   #else
   #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 6, 0)
        retval = get_user_pages(addr, 1, 1, 0, &page, NULL);
   #else
        retval = get_user_pages(current, current->mm, addr,
                    1, 1, 0, &page, NULL);
   #endif
   #endif

6. Then, in file vmmon-only/linux/hostif.c in function HostIFGetUserPages() that's around line 1158, change the following
   

   #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 6, 0)
      retval = get_user_pages((unsigned long)uvAddr, numPages, 0, 0, ppages, NULL);
   #else
      retval = get_user_pages(current, current->mm, (unsigned long)uvAddr,
                              numPages, 0, 0, ppages, NULL);
   #endif

   with
   

   #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 9, 0)
      retval = get_user_pages((unsigned long)uvAddr, numPages, 0, ppages, NULL);
   #else
   #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 6, 0)
      retval = get_user_pages((unsigned long)uvAddr, numPages, 0, 0, ppages, NULL);
   #else
      retval = get_user_pages(current, current->mm, (unsigned long)uvAddr,
                              numPages, 0, 0, ppages, NULL);
   #endif
   #endif

7. Create new vmmon.tar and vmnet.tar using the following commands:
   

   tar cf vmnet.tar vmnet-only
   tar cf vmmon.tar vmmon-only

8. Start vmware as you would normally start it. This will trigger module compilation and everything should work.

Note that you are doing everything at you own risk! :)

Fedora 24, kernel 4.7 and VMWare Workstation 12.1.

As usual, when Fedora upgrades kernel to a new major version VMWare stops working. In this particular case my Fedora was upgraded to Linux kernel version 4.7.2. The fix I found is the following one:

# cd /usr/lib/vmware/modules/source
# tar xf vmnet.tar
# mv vmnet.tar vmnet.old.tar
# sed -i -e 's/dev->trans_start = jiffies/netif_trans_update\(dev\)/g' vmnet-only/netif.c
# tar cf vmnet.tar vmnet-only
# vmware-modconfig --console --install-all

And that was it!

Note that this works if you upgraded from linux kernel version 4.6. In case you've upgraded from some earlier version, you'll have to patch it first for those version. Here is how to patch VMWare Workstation to work with Linux kernel version 4.6.

Quick note about Fedora 24 and VMWare Workstation 12.1

I just updated Fedora 24 from update-testing repository and that pulled Linux kernel 4.6. Well, as usual, VMWare Workstation needed some patching in order to work. Luckily, I quickly found a fix on VMWare forums. Note that at the end of the thread there is a script you can use to automatically patch necessary files. But, be careful, I didn't try it!

Anyway, after patching, run:

vmware-modconfig --console --install-all

and that should be it!

Just as a sidenote, turns out that the same info I found on Arch Wiki page devoted to VMWare. And that page is full of information so you should bookmark it and whenever you have a problem with VMWare check there.

Edit 20160707: The script mentioned above had some errors in it. Here is the fixed version.

Fedora 23 and VMWare Workstation 12.1

In the post about VMWare 11 I wrote about the problem that newest Fedoras are compiled using gcc5 which breaks C++ ABI thus making VMWare unrunnable. Several commenters suggested workarounds of which the simplest and most elegant solution is by user Andy who suggested that before running vmware command the environment variable LD_PRELOAD should be set to /usr/lib/vmware/lib/libglibmm-2.4.so.1/libglibmm-2.4.so.1, i.e. you should execute the following command:

export LD_PRELOAD=/usr/lib/vmware/lib/libglibmm-2.4.so.1/libglibmm-2.4.so.1 /usr/bin/vmware

This works for VMWare 12 as it did for VMWare 11.

Now, at some point it will happen that VMWare notifies you about newer version and offers you to download it and install it. But, you won't be able to run update and you'll receive the following error message:

/tmp/vmis.lLCMq3/install/vmware-installer/vmware-installer: line 56: 14595 Aborted (core dumped) VMWARE_INSTALLER="$VMWARE_INSTALLER" VMISPYVERSION="$VMISPYVERSION" "$VMWARE_INSTALLER"/vmis-launcher "$VMWARE_INSTALLER"/vmware-installer.py "$@"

What you have to do in that case is to manually download update and start it without defining LD_PRELOAD variable. Note that if you changed /usr/bin/vmware after upgrade you'll have to change it again.

Intercepting and redirecting traffic from VMWare Workstation

After some time I decided to try again sslstrip (note that there is enhanced version of sslstrip on GitHub). First, I tried to do everything on a single host, i.e. sslstrip is running on a same machine as is browser whose traffic I wanted to intercept. It turned out that this isn't so easy because there is no rule for iptables that would allow me to differentiate traffic of Firefox and SSLStrip.  Because of that fact, if I were to redirect traffic that tries to go the port 80 on the Internet so that Firefox's traffic goes to SSLStrip, I would also redirect traffic from SSLStrip to itself creating infinite loop. For some reason filtering based on PID, a.k.a. process identified, isn't possible. It used to be possible, but then it was removed. There are two solutions to overcome the problem of running everything within a single OS:

1. Run SSLStrip as a separate user (or Firefox as a separate user). IPTables allows match on UID, or
2. Run Firefox or SSLStrip in a separate network namespace.

Instead, I decided to use VMWare Workstation (I had a version 11.1.2 when I wrote this post) and to intercept its traffic. The reason I chose VMWare was that I had one virtual machine already running at hand. But it turned out that it isn't so easy, either. In the end, the problem was caused by my lack of understanding on how VMWare Workstation works. Additional problems were caused by delays that happen after changing network parameters, i.e. it takes time that the changes take effect and thus to be observable.

So, the main problem was that traffic generated by the virtual machine isn't intercepted by standard Netfilter rules when default configuration is used along with NAT networking. To see why, look at the following figure which show logical network topology:

The figure shows that traffic from Guest OS goes to virtual switch (vswitch) and then to the external network bypassing Host's netfilter hooks. So, even though there is vmnet8 in the host OS and traffic can be seen on the given interface, it doesn't go through standard NETFILTER hooks. Actually, vmnet8 is Host's interface to virtual switch. Also, if you take look at how the network is configured within Guest OS you'll note that the gateway address is set to x.y.z.2 while IP address of vmnet8 is x.y.z.1.

The behavior when the gateway is x.y.z.2 is:

1. If you try to filter packets going from Guest OS to the Internet using iptables you won't succeed. I tried to put DENY rule in filter table of all chains and it didn't work. Actually, nothing will work as netfilter hooks aren't called at all.

So, the trick, in the end, is to change default GW on Guest OS so that traffic is routed to HostOS where you can then manipulate it. In that case you'll have to also:

1. enable IP forwarding (/proc/sys/net/ipv4/ip_forward) on Host OS.
2. Activate NAT or masquerade for outgoing traffic if you want guest machine to communicate with the outside world!

Note that you can observe some delay between setting some parameter/behavior (like adding NAT rule) and the time the behavior starts to be observable, i.e. it works. Anyway, at this point you can redirect network traffic, in other words, you can then use netfilter hooks.

So, to finish this post, you should start SSLStrip and add the following rule on Host OS:

iptables -A PREROUTING -t nat -i vmnet8 -p tcp \
        --dport 80 -j REDIRECT --to-port 10000

And then try to access, e.g. http://www.facebook.com. Be careful that you didn't previously access Facebook because in that case browser will know it must use https and it won't try to use http, even if you typed it in the URL bar. If this happens than just clean the complete browser history and try again.

VMWare Workstation 10/11 on Fedora 23 Beta

UPDATE. Take a look at the comment by Vincent Cojot below for a solution on how to run VMWare Workstation/Player on Fedora 23. Take care only to go into /usr/lib/vmware/lib instead of /usr/lib/vmware as pointed out by wolf (comment after), but other than that, everything works! Note that you must not change and/or set LD_LIBRARY_PATH as first suggested by this post!

I decided to upgrade one of my laptops from Fedora 22 to the newest Fedora 23 Beta. The upgrade process went smoothly but when I tried to run VMWare, it just silently failed. Googling around for Fedora 23 and VMWare Workstation didn't help. Then, I stumbled on this thread, about the problem that VMWare installation has with GCC 5.1 used on SuSE. Turns out that the same version is used on Fedora 23, so I tried the solution from a given thread which suggest the modification of LD_LIBRARY_PATH due to the missing symbol in system provided library gtkmm:

$ export LD_LIBRARY_PATH=/usr/lib/vmware/lib/libglibmm-2.4.so.1/:/usr/lib64/gtk-2.0/modules/:$LD_LIBRARY_PATH
$ vmware
(vmware-modconfig:11918): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
(vmware-modconfig:11918): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
/usr/share/themes/Adwaita/gtk-2.0/gtkrc:1163: error: unexpected identifier `direction', expected character `}'
/usr/share/themes/Adwaita/gtk-2.0/gtkrc:1163: error: unexpected identifier `direction', expected character `}'
(vmware-tray:12017): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
(vmware-tray:12017): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
/usr/share/themes/Adwaita/gtk-2.0/gtkrc:1163: error: unexpected identifier `direction', expected character `}'

Basically, this helped a bit because now vmware doesn't fail silently. Yet, it still doesn't start. In the end, it seems that the problem is a bit more complex, as explained in this thread, so in case you need VMWare Workstation, don't upgrade yet. :)

VMWare Workstation 11 and Linux kernel 3.19

Well, I thought that starting with kernel 3.18 there will be no need any more for manual patching in order to make VMWare Workstation 11.0 work again (11.1 didn't work either). But, I was wrong. After updating vmnet compilation ended with errors and I had to search for a solution. I found it, on ArchWiki pages. Now, it happened once before to me that I just pointed to a page with a solution, and that page was changed so that solution disappeared. To avoid this, here is step by step what you have to do. First, download a patch. You don't need to be a root to execute this command:

$ curl http://pastie.org/pastes/9934018/download -o /tmp/vmnet-3.19.patch

Now, switch to root and execute the following commands:

# cd /usr/lib/vmware/modules/source
# tar -xf vmnet.tar
# patch -p0 -i /tmp/vmnet-3.19.patch
# mv vmnet.tar vmnet.tar.SAVED
# tar -cf vmnet.tar vmnet-only
# rm -r vmnet-only
# vmware-modconfig --console --install-all

And that should be it.

How to experiment and learn about BIOS malware

While trying to make VMWare Workstation work with new kernel in Fedora 20, on the link where I found solution there is a section about extracting BIOS. This section has a subsection in which it is shown how to use custom BIOS for some virtual machine. Because lately I'm all in malware analysis stuff, it occurred to me that this is actually a great opportunity to experiment with BIOS malware for educational and research purposes. Using real hardware for that purpose would be very problematic because it's not easy to modify BIOS just like that. So, in essence, what we would like to do is:

1. Extract BIOS used by VMWare.
2. Decompile it.
3. Modify.
4. Compile.
5. Install and use.

So, while searching how to do that I stumbled on PHRACK magazine's article that describes just that, how to infect BIOS. It also describes how to instruct VMWare to stop in BIOS and allow gdb to be attached for BIOS debugging! In the end, it turned out that this topic is well studied already. Here are some interesting resources I found:

1. http://www.exfiltrated.com/research.php
2. http://www.endeer.cz/bios.tools/bios.html
3. https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf
4. https://sites.google.com/site/pinczakko/pinczakko-s-guide-to-ami-bios-reverse-engineering-1
5. http://stackoverflow.com/questions/1737095/how-do-i-disassemble-raw-x86-code
6. http://duartes.org/gustavo/blog/post/how-computers-boot-up/
7. http://duartes.org/gustavo/blog/post/motherboard-chipsets-memory-map/
8. PHRACK: Persistent BIOS infection
9. https://www.bios-mods.com/downloads/
10. https://www.kraxel.org/repos/
11. https://www.kraxel.org/blog/
12. https://www.wimsbios.com/forum/depth-high-tech-bios-section-f37/

So, I stopped there with old BIOS stuff. It is clear that everything needed is there. So, I started to think about UEFI.

Lately, UEFI is much more interesting to experiment with because gradually all the manufacturers are switching from old BIOS to a new boot method that has additional protections. It turns out that VMWare Workstation, starting with version 8 supports UEFI boot, too. All that is necessary is to add the following line to vmx configuration file of a virtual machine:

firmware="efi"

So, this is a great research and learning opportunity. Yet, it is very hard to find information on how to manipulate UEFI BIOS. One reason might be that it is relatively new and not many people know what it does and how it works.

While searching for information on how to infect and manipulate UEFI, I found the following URLs to be interesting:

1. http://www.projectosx.com/forum/index.php?showtopic=3018
2. http://wiki.osdev.org/UEFI
3. http://uefi.org/learning_center/presentationsandvideos
4. http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/
5. http://tianocore.sourceforge.net/wiki/Welcome
6. http://vzimmer.blogspot.com/2012/12/accessing-uefi-form-operating-system.html

Fedora 20 update to kernel 3.17.2-200 and VMWare Workstation

Since I updated to VMWare Workstation 10.0.5 at the end of January 2015, things were again broken. Returning to this post I found that the link in the post now points to something that has changed and there is no patch nor instructions of what to do. So, I had to google again and now I placed the complete instructions in this post so that the next time I don't have to google again.

It turns out that there is a single line that has to be changed in the vmnet module in order for VMWare to be runnable again. So, here are the steps you have to do in order to patch the file:

1. Create temporary directory, e.g. /tmp/vmware and position yourself in that directory.
2. Create a file named vmnet.patch and put into it the following content:
   
   

   diff -ur vmnet-only.a/netif.c vmnet-only/netif.c
   --- vmnet-only.a/netif.c    2014-10-10 03:23:08.585920012 +0300
   +++ vmnet-only/netif.c  2014-10-10 03:23:09.245920008 +0300
   @@ -149,7 +149,7 @@
       memcpy(deviceName, devName, sizeof deviceName);
       NULL_TERMINATE_STRING(deviceName);
   
   -   dev = alloc_netdev(sizeof *netIf, deviceName, VNetNetIfSetup);
   +   dev = alloc_netdev(sizeof *netIf, deviceName, NET_NAME_UNKNOWN, VNetNetIfSetup);
       if (!dev) {
          retval = -ENOMEM;
          goto out;
   

   
   
3. Unpack /usr/lib/vmware/modules/source/vmnet.tar in the current directory (/tmp/vmware):
   
   

   tar xf /usr/lib/vmware/modules/source/vmnet.tar
   

   
   
4. Patch the module:
   
   

   cd vmnet-only; patch -p1 < ../vmnet.patch; cd ..
   

   
   
5. Make a copy of old, unpatched, archive:
   
   

   mv /usr/lib/vmware/modules/source/vmnet.tar /usr/lib/vmware/modules/source/vmnet.tar.SAVED
   

   
   
6. Create a new archive:
   
   

   tar cf /usr/lib/vmware/modules/source/vmnet.tar vmnet-only
   

   
   
7. Start vmware configuration process:
   
   

   vmware-modconfig --console --install-all
   

Hopefully, that should be it.

Old instructions (not valid any more!)

Well, here we go again. After recent update which brought kernel 3.17 to Fedora 20, VMWare Workstation 10.0.4 had problems with kernel modules. Luckily, after some short googling I found a solution. That solution works. There are two things that might confuse you though:

1. After cd command and before for loop you have to switch to root account (that is indicated by prompt sign change from $ to #).
2. The substring kernel-version in patch command should be replaced with a string "3.17". That is actually the name you gave to a file while executing curl command at the beginning of the process.

Anyway, that's it.

Kernel upgrade to 3.13.3-201 and VMWare Workstation...

I just started VMWare for the first time after upgrade and restart into kernel 3.13.3-201, and it didn't work. Well, I already got used to it. Anyway, the fix was very quick. I found a patch in a post on VMWare forums, downloaded it and applied it. The application process is a bit more manually involved that with the previous patches. You need to:

1. Switch to root user.
2. Go to the /usr/lib/vmware/modules/source directory
3. Unpack vmnet.tar using tar command.
4. Enter into newly created vmnet-only directory
5. Apply patch (patch -p1 < path_and_name_of_unpacked_patch_file). Patch shouldn't make any noise, only patched file is displayed.
6. Go one level up (exit vmnet-only directory)
7. Rename existing vmnet.tar into something else, just in case.
8. Create new vmnet.tar (tar cf vmnet.tar vmnet-only)
9. Start vmware

And that's it...

Problem with automatic VMWare upgrade from 9.0.1 to 9.0.2

VMWare Workstation checks upon startup if there are new version of the software, and if it is then it asks you if you want to upgrade. In case automatic checking is disabled, there is an option under the Help menu that allows manual triggering of that process. For some time now I was getting notification about free upgrade from 9.0.1 to 9.0.2 which I would enable, but which never finished for unknown reason. Instead of trying to figure out what was wrong I decided to try to do it manually. In the end, it turned out to be a semi-manual process. Namely, when I received an error message about being unable to upgrade I looked where downloaded files are. It turned out that they are stored in /tmp directory but that they have UUID like names, i.e.:

$ ls -l
total 381768
-rw-r--r--.  1 sgros zemris  66211840 Kol 29 13:28 06dd4484-5c02-4c5d-992c-ff705703e6cb
-rw-r--r--.  1 sgros zemris  11253760 Kol 29 13:29 1cf5e724-f7d4-4f24-b484-30ebb16d593e
-rw-r--r--.  1 sgros zemris  61777920 Kol 29 13:29 2007e14d-3593-416f-b60e-08c4cd18693a
-rw-r--r--.  1 sgros zemris 232693760 Kol 29 13:31 364c998b-8b3b-4cfd-a2dc-67352a3eb082
-rw-r--r--.  1 sgros zemris  13096960 Kol 29 13:31 4b7424a6-e114-4832-be21-f0a3acf8c24b
-rw-r--r--.  1 sgros zemris     81920 Kol 29 13:31 8a8d105f-fd3d-404a-afc9-28411d6566fe
-rw-r--r--.  1 sgros zemris   5795840 Kol 29 13:31 d969898b-30bb-4c6d-bf45-5a7d52918359

Now, using file command it was easy to determine that they are actually tar archives so. So, I created new directory and unpacked all those files there. What I've got was one file with extension bundle and several files with an extension component.

# ls -l
total 390904
-rw-r--r--. 1   201    201      1161 Vel 26  2013 descriptor.xml
-rw-r--r--. 1   201    201  15207519 Vel 26  2013 vmware-tools-freebsd-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201  66202162 Vel 26  2013 vmware-tools-linux-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201     76615 Vel 26  2013 vmware-tools-netware-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201  13088243 Vel 26  2013 vmware-tools-solaris-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201  61771010 Vel 26  2013 vmware-tools-windows-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201  11247429 Vel 26  2013 vmware-tools-winPre2k-9.2.3-1031769.x86_64.component
-rwxr-xr-x. 1 sgros zemris 232680125 Vel 26  2013 VMware-Workstation-9.0.2-1031769.x86_64.bundle

The bundle type file is actually an installer for a new version of VMWare, so I've run it as a root user and it installed new version of VMWare. The component files, on the other hand, have to be installed using vmware-install tool, e.g. to install vmware-tools-windows-9.2.3-1031769.x86_64.component file, execute the following command as a root user:

vmware-installer --install-component=vmware-tools-windows-9.2.3-1031769.x86_64.component

The same command has to be repeated for the other files too. But, note that those files are optional, depending what you've running. You can check which components you have installed using vmware-installer command with an option -t, i.e.
vmware-installer -t
And that was it. Of course, before being able to run VMWare I had to patch it again. But that was it.

VMWare Workstation and kernel 3.10 (again)

Change in the kernel version again broke VMWare Workstation. It would definitely be the best option for VMWare to try to integrate their modules into the kernel. In such a way maintenance of those modules would be bound with kernel and a lot of people would have a lot less annoyance. But, that's not the case and so such problems happen. In this case, the solution is again relatively easy. Just run the following commands, as is, and everything should work:

cd /tmp
curl -O http://pkgbuild.com/git/aur-mirror.git/plain/vmware-patch/vmblock-9.0.2-5.0.2-3.10.patch
curl -O http://pkgbuild.com/git/aur-mirror.git/plain/vmware-patch/vmnet-9.0.2-5.0.2-3.10.patch
cd /usr/lib/vmware/modules/source
tar -xvf vmblock.tar
tar -xvf vmnet.tar
patch -p0 -i /tmp/vmblock-9.0.2-5.0.2-3.10.patch
patch -p0 -i /tmp/vmnet-9.0.2-5.0.2-3.10.patch
tar -cf vmblock.tar vmblock-only
tar -cf vmnet.tar vmnet-only
rm -rf vmblock-only
rm -rf vmnet-only
vmware-modconfig --console --install-all

The commands were taken from this link. Note that curl commands are broken to two lines due to the space problems, but they should be typed in a single line. I tried this with VMWare Workstation 9.0.1 and kernel 3.10.9 and it worked flawlessly.

Fedora 18 and update to kernel 3.8.1

Today, I updated Fedora 18 and, as a consequence, kernel was also updated to version 3.8.1. Up until now, after each upgrade only thing I had to do is to softlink version.h file (see this post, section Virtualization). But now, VMCI module didn't compile either. Luckily, some had the same problem during RC status of kernel 3.8 and they successfully solved it. :) I tried it, and it worked flawlessly.

You need to download the patch and then execute the following commands (as a user root):

cd /usr/lib/vmware/modules/source
cp vmci.tar vmci.tar.SAVED
tar xf vmci.tar
cd vmci-only
patch -p1 < path to downloaded patch filecd ..
tar cf vmci.tar vmci-only/
rm -rf vmci-only

Be careful with the last rm command. :) Also, cp command is only precaution, if something goes wrong, you have a copy of old vmci.tar archive.

Anyway, just for the completeness here is what you should do to fix missing version.h file:

cd /usr/src/kernels/3.8.1-201.fc18.x86_64/include/linux
ln -sf /usr/src/kernels/3.8.1-201.fc18.x86_64/include/generated/uapi/linux/version.h .

And that's it. Probably soon will appear all-in-one-patch that will streamline this whole procedure.

Fedora 18 installation

The first day of 2013. I switched to a new laptop, Lenovo W530, and Fedora 18. In this post I'll document what works and what doesn't work. Note that because of that this will be live post. Basically, this post originates from somewhere around Fedora 16 time and I never got it into the state I thought it was good enough to be published. But, then, I realized that it will never be finished, so I decided to turn it to published post. Note that I reworked this post to be exclusively about Fedora 18 on Lenovo W530. At the time this installation was performed Fedora 18 was still in beta stage, so, things might differ after Fedora 18 final is released. I decided to publish this post in unfinished state and to use it to document the progress I'm having with transition to a new laptop.

As usual, there are other resources on the Internet about Linux on W530, and here are some more interesting I managed to find:

• Lenovo ThinkPad W530
• Ubuntu on ThinkPad T430s (and W530)
• Enabling external monitor on Lenovo W530 with Nvidia Discrete Graphics and Ubuntu Linux 12.04
• Installing Fedora 17 on W530

Also, there are some pages with information (somewhat) relevant to this combination (Fedora 18 and W530):

• Bumblebee project
• Fedora 18 Beta on Thinkpad T430s

Hardware

I bought the W530 with 1T internal disk and 8GB RAM. And this was pretty good deal for this laptop. Additionally, on eBay I bought 512GB SSD disk and 32GB of RAM (4x8GB). The monitor has resolution of 1920x1600 and NVidia Card. The resolution was one of the things I wasn't particularly happy with the previous laptop, which has 1600x1080.

Installation and first boot

I decided to use PXEBOOT to boot the machine and then to install it over the network. It turned out that I had some problems with DHCP on my work network. Additionally, I had problems with Fedora's new installer which cause many errors during disk partitioning time. Everything boiled down to BTRFS selection being completely broken. LVM was much better, but it also had some quirks (like embedding host name in logical volume names). This host embedding was removed later. It should be noted that this was constantly worked on so if I tried the same thing some other day, it could work. But, I didn't want to wait for some other day and in the end, I decided to mirror Fedora 18 development repository on my previous laptop and then to install it from there. The setup was basically the following one: old and new laptops connected with crossover Ethernet cable, and the old laptop was connected to the Internet with wireless Ethernet. On old laptop I mirrored the whole Fedora 18 directory tree. I also configured DHCP/TFTP and Apache to be able to do installation. I won't go into details how to do that because there is a manual on Fedora pages which is quite good.

First boot

First boot is as usual except one tiny annoyance. Namely, for my UID and GID I use a specific values for a long time and first boot configuration screen doesn't allow me to proceed without defining new user while in the same time it

Customizations

Customization consists of tweaks to the system and adding external repositories in order for me to be able to install mplayer and similar software not distributed within Fedora, at least not in a usable way.

System customizations

One thing I change is the following line in the /etc/nsswitch.conf file:

hosts:     files mdns4_minimal [NOTFOUND=return] dns

to be

hosts:     files dns

The reason is that in some local networks I'm using .local domain suffix and by default such names are resolved using mDNS (mdns4_minimal option). Since I'm using regular DNS for those names too, then they are unresolvable unless I make this change.

RPM Fusion

RPM Fusion has some packages that are not shipped with Fedora. For example, different audio and video codecs are not in Fedora due to the patent or some other issues. In that case you need RPM Fusion. RPMFusion supports different versions of Fedora, you can find a list here. You have to select one free and one non-free repository, copy link and paste it to the terminal as an argument to 'rpm -i' command, or 'yum localinstall' command. This will add necessary yum configuration files. Now, you can install, for example, mplayer and vlc:

yum install mplayer vlc

There are other interesting packages, but I'll let you explore those for yourself.

Adobe Flash and Acroread

YouTube works without Flash thanks to the HTML5 support in Firefox. But, not all videos on YouTube can work in HTML5 and also, there are sites on the Internet that can not live without Flash, so it has to be installed too.

On the download page there is an option to retrieve YUM configuration files. So, chose YUM and then you'll be offered to download file, about 4K in size. After you download it somewhere to your disk, install it using 'yum localinstall' command. Now, you can install flash using the following command:

yum install flash-plugin

As for Acrobat Reader, you have to download rpm file and install it "manually". But, I think that it isn't so necessary because Evince works very well. There are sporadic cases when Evince has problems, mainly due to the fonts, but otherwise it's very good replacement.

Google Chrome

To install Google Chrome you'll need first to install Google Chrome manually and then it'll add Google Chrome repositories. But, you can skip "manual" installation, i.e. add yum repository and install Chrome using yum. To do so create file /etc/yum.repos.d/google-chrome.repo and copy the following content into that file:

[google-chrome]
name=google-chrome
baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64
enabled=1
gpgcheck=1

Additionally, you have to install Google's signing key (or set gpgcheck in yum configuration file to 0, which is not advisable). Anyway, use the following two commands to import Google's rpm signing key:

wget https://dl-ssl.google.com/linux/linux_signing_key.pub
rpm --import linux_signing_key.pub

Now, just run yum install google-chrome-beta.x86_64, or google-chrome-stable.x86_64 or google-chrome-unstable.x86_64; depending on which version you want to run. Note that there are some other packages in the Google's Chrome repository. Use 'yum list google\*' command to get a list of those.

Virtualization

Fedora has a lot of virtualization options to choose from.

VirtualBox is part of RPMFusion free repository. So, you don't need to add anything extra to be able to install it, just run:

yum install VirtualBox

and that's it. Alternatively, you might want to install "official" Oracle's version. Oracle has yum repositories for Fedora (though not for Fedora 18 at the time this post was written) which you can find here, along with instructions on how to install those repositories.

In case you are using VMWare Workstation, you'll have to download it from the VMWare's Web pages. I downloaded 64-bit trial version of VMWare 9.0.1 and installed it. It works, even though during installation process it created a file named ~ (tilde). It had exactly 1K, but I don't know what it is. Could be some problem in the installation script. Apart from that, seems that VMWare works without any problems.

Note that on January 6th, kernel was updated to version 3.7.1 (to be precise 3.7.1-2). VMWare, as of 9.0.1, isn't compatible with that version of kernel and it doesn't work! But, the solution is simple and easy to find on a net, execute the following commands (as root) and everything should work again:

cd /usr/src/kernels/3.7.1-2.fc18.x86_64/include/linux
ln -sf /usr/src/kernels/3.7.1-2.fc18.x86_64/include/generated/uapi/linux/version.h .

That are two lines,but ln command is broken on a dash sign so when copying it join the two parts together without any spaces in between. Also, if the kernel version is different just change appropriate substrings.

In case you have version 3.7.1-5 then version.h is removed and when you start VMWare Workstation it says it needs to rebuild drivers and after you confirm that then it complains that there are no kernel headers. To fix this problem, execute the following two lines:

cd /usr/src/kernels/3.7.1-5.fc18.x86_64/include/linuxln -sf /usr/src/kernels/3.7.1-5.fc18.x86_64/include/generated/uapi/linux/version.h .

Removing unnecessary software

This is something I did very thoroughly before, but as the time passes I do it less and less. The disk space these days is very cheap and there is a plenty of it, also inter dependencies between packages are complex, so these days I do only few adjustments.

Removing Asian and Arabic fonts

I decided to remove those simply because it annoys me to have such a large number of options in dialogs where I need to select font to use, many of which I simply don't understand! So, I removed the packages that start with paktype and lohit using yum (i.e. issue yum remove paktype\*, lohit\*), wqy-zenhei-fonts, thai-scalable-waree-fonts, cjkuni-uming-fonts, jomolhari-fonts, vlgothic-fonts vlgothic-fonts-common un-core-dotum-fonts smc-meera-fonts sil-padauk-fonts sil-abyssinica-fonts paratype-pt-sans-fonts lklug-fonts khmeros-base-fonts.

UI Tweaks

I installed gnome-tweak-tool, gcond-editor and dconf-editor packages to be able to tweak UI. Basically, a lot of things can be done from the Gnome's Tweak tool. But many can not. For example, modal windows by default are attached to a windows that opened them, like it is done on MacOS X. But, I prefer them to be detached so that I can move them and access content behind them. So, to change this behavior you should set /desktop/gnome/shell/windows/attach_modal_dialogs to true, e.g. like this (note that this should be a single line):

gconftool-2 --toggle /desktop/gnome/shell/windows/attach_modal_dialogs

This will toggle the value, if it was true it will become false and vice versa. To query current state use the following form:

gconftool-2 --get /desktop/gnome/shell/windows/attach_modal_dialogs

If you want to disable Fedora package search in Gnome, there is a boolean key that controls that: org.fedoraproject.fedorapackages.search. Also, when you install Fedora fedmsg is enabled by default. You can disable it by toggling its key org.fedoraproject.fedmsg.notify.enabled.
 For the last two keys you should use dconf, not gconf. Also note that I had some problems using command line client (probably my fault), so I suggest you use editor to inspect and change those values.

Successes and Problems

Failed login problem

For some unknown reason I'm unable to login in GNOME if SELinux is enabled. So, when I boot machine I have to first switch to some virtual console, login there as a root and issue 'setenforce 0'. I could do that accross boots (by modifying /etc/sysconfig/selinux file) but I want SELinux to be enabled so I'm waiting for this issue to be fixed.

 Audio problem

I had problems trying to play audio. Can't remember if that was the problem from the beginning or only after some update I did. Anyway, it turns out the problem is with permissions. Namely, I, as an ordinary user, don't have permission to access devices and so PulseAudio is using dummy device. I searched a bit, but couldn't find. Temporary fix is to switch to root user and change ownership of /dev/snd directory to my username (chown -R username /dev/snd). Basically, PulseAudio immediatelly notices this and activates sound.

Video problems

Because of permissions I also had problems with gnome-shell and video. Namely, gnome-shell was taking 400% CPU (well, 4 CPUs actually) but the problem was that it was doing software rendering. Running gnome-shell from the command line I got the following error:

libGL error: failed to load driver: i965
libGL error: Try again with LIBGL_DEBUG=verbose for more details.

Two things confused me here. First, is X11 using NVidia or Intel? And second, why it was failing? So, I rerun gnome-shell with LIBGL_DEBUG set to verbose (and exported) and it was a bit more informative:

libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965
libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so
libGL: Can't open configuration file /home/sgros/.drirc: No such file or directory.
libGL: Can't open configuration file /home/sgros/.drirc: No such file or directory.

When I saw permission errors I immediately knew that this was the same bug as for audio. So, I did again chown -R username /dev/dri and restarted gnome-shell. Now, gnome-shell wasn't even on the process list.

As for the question Intel or NVidia, glxinfo shows that it is using Intel. When I rebooted and looked into BIOS settings it turned out that NVIDIA Optimus dispaly setting was selected. What that setting does is that it activates both cards, but Intel is used by default and NVidia only when requested. To be able to use such configuration you'll need to install Bumblebee program.

Conclusion

As of this writing, to have working GNOME and to be able to login, after boot finishes and GDM presents you with a login screen you should switch to second virtual console (Alt+F2), login as root and execute the following commands:

setenforce 0
chown username /dev/dri /dev/snd

This isn't necessary any more, at least not on fully patched Fedora 18 as of March 4th.

Other notes

After working on W510 for two years I have to say that I'll need for some things time to get used to. First, keyboard is a bit different. Esc key is much smaller, PgUp and PgDn are with arrow keys instead in top left part of the keyboard. Actually, I'll have to get used to the placement of all the other navigation keys as well.

Also interesting is that there is no Caps Lock keyboard indicator, also, there are no Num Lock and Scroll Lock keys. It is problematic when you turn on Caps Lock without knowing it and suddenly things don't work and you don't know why until you realize that the problem is in Caps Lock. I think there should be led indicator on the keyboard, but since there isn't I found gnome shell extension that adds indicator to the panel. Since I don't have Num Lock I turned out its indication.

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.

VMWare Workstation DNS server...

I just figured out very interesting thing about DNS server used by VMWare virtual machines. It uses /etc/hosts file on host machine to resolve names. The trick is that those names have to have .localdomain suffix. So, for example, if you have the following entry in /etc/hosts file of host machine:

1.1.1.1        test

and then you ask with nslookup within guest machine for that name, you'll receive:

# nslookup test
Server: 192.168.178.2
Address: 192.168.178.2#53

Name: test.localdomain
Address: 1.1.1.1

Note that localdomain is automatically appended. This is specified with search directive in /etc/resolv.conf of guest machine (there is a line search localdomain or something similar). Otherwise, without localdomain, the name wouldn't be found:

# nslookup test.
Server: 192.168.178.2
Address: 192.168.178.2#53

** server can't find test.: NXDOMAIN

In this example, the dot I appended after the name prevents anything from being appended and only name test is looked for.

To conclude, the rule is simple. If the name to be looked up ends with localdomain, then it is searched within /etc/hosts file of the host operating system.

I discovered this by accident. Namely, I did nslookup within guest machine expecting to receive error message about non-existing host name, but I got good response!? At first, I was confused, and it took me several minutes to figure out what's happening. Well, so the things go when you don't read manuals. ;)

VMWare Workstation on Fedora 17...

Today, when I started VMWare Workstation, it notified me that there is a free security update. Since it is advisable to update whenever there are security issues, I approved it, but of course that after update I had a problem starting VMWare workstation. Since there are constantly problems with VMWare and Fedora I finally decided to track everything I had to do in this post. In other words, this post will be updated whenever I have to do something to VMWare Workstation to get it to work.

Ok, as I said, on a fully updated Fedora 17 (kernel-3.4.2-4.fc17.x86_64) when a new VMWare Workstation 8.0.4 is installed (or updated) it can not configure itself because of errors in kernel modules. As I wrote this I wasn't able to find a patch that fixes everything in one step, but I managed to combine two fixes that allowed VMWare to start. First, I had to apply patch for 8.0.3 that fixed vmnet.tar file. To do that I also had to modify a bit the script distributed with patch so that it accepts the fact that I'm using a newer version of VMWare (i.e. 8.0.4 instead of 8.0.3). Then, I had to apply a small fix for vmblock.tar that I wrote about in other post. Finally, I tried to start VMWare Workstation but it failed again?! After a bit poking, I realized  that there were dangling processes/modules so I had to kill all VMWare processes, remove modules, and that start succeeded. Of course that I could also restart the laptop, but because of the number of open windows I have, that wasn't an option. :)

When I did all that, then I found out that there is a patch that does all this, i.e. those two steps but combined, but it is for VMWare Workstation 8.0.2, which means you still have to poke a bit in script that applies a patch. And finally, this blog seems to be a good place to look when you have some problems with VMWare (and VirtualBox) and newer versions of kernel.

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.

Keyboard autorepeat...

It happens from time to time that the keyboard autorepeat suddenly stops working. It just happened to me after I used VMware with Windows 7 as a guest operating system. I don't believe it's Windows' fault. Actually, I'm quite certain that it isn't! :) It's probably fault of VMware's mouse and keyboard driver that allows seamless integration of desktops.

Anyway, it is very annoying when autorepeat doesn't work, so I Googled a bit and found out that using 'xset q' should show me wether the autorepeat is on or off. What I got was:

$ xset q
Keyboard Control:
  auto repeat:  off    key click percent:  0    LED mask:  00000000
  XKB indicators:
...

So, it was obvious that autorepeat is turned off. It was relatively straightforward to find how to turn it back on. It's just necessary to run 'xset r', and it was on again:

$ xset r
$ xset q
Keyboard Control:
  auto repeat:  on    key click percent:  0    LED mask:  00000000
  XKB indicators:
...

That made me very happy as I didn't need to restart X session. It's a nightmare to restart X (or just logout) since I have over hundred opened tabs in Firefox...