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...

Upgrade to Fedora 20

This is a log of my tries to upgrade from Fedora 19 to Fedora 20 using fedup. The upgrade process wasn't really so flawless, but that was for three reasons. The first one was that on my laptop I have installed too many packages which creates problems by itself. Namely, on almost every update I have some problems with dependencies, so, it was expected to have problems during upgrade, too. Second problem was that I didn't pay attention to some details. Now, it might be argued that less skilled people will pay even less attention, and so, this will be a problem for them too, but then, I don't know. Finally, there was a third problem as well, and that were bugs in fedup package.

Ok, theoretically, to upgrade Fedora 19 to 20 you only have to do the following:

# fedup --network 20

and after that command finishes, reboot and the upgrade process will start. Finally, after one more reboot, you are in a new environment/OS. Of course, the process is a long one because everything is downloaded from the Internet. There is an option of using ISO image and downloading only updates/external repositories, but I didn't try it.

Problems

The first problems were related to available disk space. When fedup started download I realized that there could be problems with space. On root (/) partition I had available only few gigabytes, so I move two directories, /var/tmp/fedora-upgrade and /var/lib/fedora-upgrade, to /home partition where there was much more space, and created symlinks in the original directories so that fedup finds them.

After starting fedup again it downloaded everything necessary (continuing from where it stopped) and then it tested transaction. One problem was with the available space on the root (/) partition. That problem I solved by uninstalling some extra large packages. The easiest way to find out which packages take the most space is to use the following command:

# rpm -q --qf '%10{SIZE} %{NAME}\n' -a | sort -n

it will print out all packages with theirs sizes sorted from the smallest to the biggest one. So, I removed few biggest ones. I also removed some packages from /opt directory that I manually installed.

Ok, after I restarted fedup it didn't download everything again but after some tests of downloaded packages it tested the upgrade transaction. The following problems were reported:

WARNING: potential problems with upgrade
  ffmpeg2theora-0.29-4.fc19.x86_64 (no replacement) requires ffmpeg-libs-1.2.4-2.fc19.x86_64 (replaced by ffmpeg-libs-2.1.1-1.fc20.x86_64)
  gcc-python3-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python3-plugin-0.12-15.fc20.x86_64) requires gcc-python3-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python3-plugin-0.12-15.fc20.x86_64)
  perl-HTML-Template-2.95-1.fc19.noarch (no replacement) requires 4:perl-5.16.3-266.fc19.x86_64 (replaced by 4:perl-5.18.1-288.fc20.x86_64)
  rubygem-audited-activerecord-3.0.0-3.fc19.noarch (no replacement) requires 1:rubygem-activerecord-3.2.13-1.fc19.noarch (replaced by 1:rubygem-activerecord-4.0.0-1.fc20.noarch)
  gnome-shell-extension-xrandr-indicator-3.8.4-1.fc19.noarch (no replacement) requires gnome-shell-extension-alternative-status-menu-3.8.4-1.fc19.noarch (replaced by gnome-shell-extension-common-3.10.1-1.fc20.noarch)
  gcc-python3-debug-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python3-debug-plugin-0.12-15.fc20.x86_64) requires gcc-python3-debug-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python3-debug-plugin-0.12-15.fc20.x86_64)
  1:NetworkManager-wimax-0.9.8.8-2.fc19.x86_64 (no replacement) requires 1:NetworkManager-0.9.8.8-2.fc19.x86_64 (replaced by 1:NetworkManager-0.9.9.0-20.git20131003.fc20.x86_64)
  gcc-python2-debug-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python2-debug-plugin-0.12-15.fc20.x86_64) requires gcc-python2-debug-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python2-debug-plugin-0.12-15.fc20.x86_64)
  gcc-python2-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python2-plugin-0.12-15.fc20.x86_64) requires gcc-python2-plugin-0.12-15.fc19.x86_64 (replaced by gcc-python2-plugin-0.12-15.fc20.x86_64)
  gazpacho-0.7.2-13.fc19.noarch (no replacement) requires python-kiwi-gazpacho-1.9.26-6.fc19.noarch (replaced by python-kiwi-glade-1.9.38-2.fc20.x86_64)
  python-iguanaIR-1.0.3-2.fc19.x86_64 (no replacement) requires iguanaIR-1.0.3-2.fc19.x86_64 (replaced by iguanaIR-1.0.5-2.fc20.x86_64)

Finally, it asked for reboot to start upgrade. But, I decided to remove offending packages which were those with f19 tag in the package name. Then, I started fedup again. It again found some problems:

WARNING: problems were encountered during transaction test:
  broken dependencies
    gazpacho-0.7.2-13.fc19.noarch requires python-kiwi-gazpacho-1.9.26-6.fc19.noarch
    perl-HTML-Template-2.95-1.fc19.noarch requires perl-4:5.16.3-266.fc19.x86_64
    python-iguanaIR-1.0.3-2.fc19.x86_64 requires iguanaIR-1.0.3-2.fc19.x86_64
    kmod-VirtualBox-3.11.10-200.fc19.x86_64-4.3.4-1.fc19.x86_64 requires kernel-3.11.9-200.fc19.x86_64, kernel-3.11.7-200.fc19.x86_64, kernel-3.11.10-200.fc19.x86_64
    gcc-python3-plugin-0.12-15.fc20.x86_64 requires gcc-python3-plugin-0.12-15.fc20.x86_64
    gnome-shell-extension-xrandr-indicator-3.8.4-1.fc19.noarch requires gnome-shell-extension-common-3.8.4-1.fc19.noarch
    rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires rubygem-activerecord-1:3.2.13-1.fc19.noarch
    ffmpeg2theora-0.29-4.fc19.x86_64 requires ffmpeg-libs-1.2.4-2.fc19.x86_64
    gcc-python2-plugin-0.12-15.fc20.x86_64 requires gcc-python2-plugin-0.12-15.fc20.x86_64
    kmod-VirtualBox-3.11.9-200.fc19.x86_64-4.3.4-1.fc19.x86_64 requires kernel-3.11.9-200.fc19.x86_64, kernel-3.11.7-200.fc19.x86_64, kernel-3.11.10-200.fc19.x86_64
    gcc-python3-debug-plugin-0.12-15.fc20.x86_64 requires gcc-python3-debug-plugin-0.12-15.fc20.x86_64
    kmod-VirtualBox-3.11.7-200.fc19.x86_64-4.3.2-1.fc19.3.x86_64 requires kernel-3.11.9-200.fc19.x86_64, kernel-3.11.7-200.fc19.x86_64, kernel-3.11.10-200.fc19.x86_64
    NetworkManager-wimax-1:0.9.8.8-2.fc19.x86_64 requires NetworkManager-1:0.9.8.8-2.fc19.x86_64
    gcc-python2-debug-plugin-0.12-15.fc20.x86_64 requires gcc-python2-debug-plugin-0.12-15.fc20.x86_64
Continue with the upgrade at your own risk.

I tried again to remove some offending packages that were reported in the previous output, and started fedup again:

# fedup --network 20
setting up repos...
getting boot images...
.treeinfo.signed                          | 2.0 kB  00:00:00
setting up update...
finding updates 100% [===========================================================]
verify local files 100% [===========================================================]
testing upgrade transaction
rpm transaction 100% [===========================================================]
rpm install 100% [===========================================================]
setting up system for upgrade
Finished. Reboot to start upgrade.

I didn't managed to get rid of all transaction problems, more specifically there were problems with kmod-VirtualBox packages. But then, I gave up of trying to fix that and decided to continue with the upgrade. At that moment I made the next mistake which was that I rebooted before fedup finished. Namely, the last thing it printed was 'Finished. Reboot to start upgrade.' but it didn't give a prompt back. I mistakenly thought that it waits for me to reboot. But, it was actually still working! So, actually, nothing happened after boot. I was again in Fedora 19. After again starting fedup and checking what's happening I finally realized that fedup is still working (and consuming a lot of CPU) so I waited and finally I got the prompt back. Then I restarted the computer, selected fedora upgrade option, but nothing happened. I rebooted, and removed rhgb and quiet options from boot option to upgrade with fedup, and the last message I saw after removing rhgb and quite options from boot entry was:

[    5.733054] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/serio2/input/input7

Waiting dropped me finally into dracut shell with a message there is no root. It turned out that this message was obscuring passphrase message! Namely, I was asked for the passphrase to unlock disk, but I didn't saw it and everything stopped. After few reboots I realized this as the message was partially visible and I finally realized what was the problem.

Then, something else happened, the upgrade process didn't start. I ended up in the Fedora 19. It also took me some time to realize that fedup "forgot" to put the following options to boot entry:

upgrade systemd.unit=system-upgrade.target

and it did it repeatedly! In other words,  So, I manually added it and the upgrade finally started. Or at least it seamed so. It stopped suddenly, but I noticed that it complained about not finding file package-list and then I realized that symlink is wrong because all the partitions are mounted under sysroot. Namely, because I moved packages to other partition and symlinked it, upgrade process couldn't find it.  Symlinks looked like this:

/var/lib/system-upgrade -> /home/system-upgrade

But during upgrade process, home is mounted under /sysroot directory. So, I had to run fedup again, and after it prepared the system for upgrade, before rebooting, I changed symlinks so that they look like this:

/var/lib/system-upgrade -> /sysroot/home/system-upgrade

Note that after reboot to upgrade if you want to try again, you have to start fedup again. Namely, immediately before upgrade process starts, the boot option is removed from grub. This is safety measure, but it is annoying in case you are trying again.

Anyway, that symlink issue was the last problem, and it upgraded Fedora 19 to 20. It took me almost half a day to get to that point and I don't call this a most pleasant experience. In other words, I think that those things should be polished a bit better than they are.

One last thing, I had problems with fedup 0.7 and I had to upgrade to fedup 0.8. This was somewhere early in the whole process, but since I started to take notes later when I stumbled upon more problems, I didn't noted exactly where it happened, so I'm mentioning it here.

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.

Upgrading to Fedora 19

I just managed to install Fedora 19 and that was harder than it should be. Here are some remarks.

One thing to note. Every system is different and when I managed to fix something, it could be that I changed something else also, at first glance unrelated, to the problem itself. Yet, I don't have time to double check each fix I did. So, treat this as hints what could you do in case you have similar problems.

Failed attempt

First, I tried to uprade using FedUp tool. But that failed. Upgrade process requires certain amount of free space on root partition. Well, I have relatively small root partition and it is isolated from /home where there is a lot of space. For this reason I had to move FedUp working directories (/var/tmp/fedora-upgrade and /var/lib/fedora-upgrade) to home partition and create symlinks. After reboot into fedup, it briefly showed exception and then rebooted again into Fedora 18. The exception was:

[     0.421] (II) fedup.sysprep:remove_cache() removing /var/tmp/fedora-upgrade
[     0.424] (II) fedup:() Exception:
Traceback (most recent call last):
  File "/usr/bin/fedup-cli", line 181, in
    main(args)
  File "/usr/bin/fedup-cli", line 82, in main
    do_cleanup(args)
  File "/usr/lib/python2.7/site-packages/fedup/commandline.py", line 183, in do_cleanup
    remove_cache()
  File "/usr/lib/python2.7/site-packages/fedup/sysprep.py", line 195, in remove_cache
    rm_rf(d)
  File "/usr/lib/python2.7/site-packages/fedup/util.py", line 51, in rm_rf
    rm_f(d, rm=rmtree)
  File "/usr/lib/python2.7/site-packages/fedup/util.py", line 48, in rm_f
    log.warn("failed to remove %s: %s", f, str(e))
NameError: global name 'log' is not defined

At first, I thought that the problem was the inability to remove a directory, but then I realised that the problem is undefined log module/class! So, I opened file /usr/lib/python2.7/site-packages/fedup/util.py and replaced line 48 with a simple pass statement.

Reinstall

Then, I decided to reinstall Fedora from scratch. But, I didn't want to burn CD nor I wanted to go again through the network boot/install process again. So, I booted from USB stick. In essence, you need to download boot.iso file and using livecd-usb-to-disk tool write it on USB stick. Then, boot from this stick and off you go.

Luckily, installation process is much improved from Fedora 18.

Problems

During a boot process, I was dropped into a single user mode. Looking into logs (as suggested by the message just before the root password prompt) I found that dbus isn't working, i.e. there was the following message:

Cannot boot - no /var/lib/dbus directory. Created the directory and disabled SELinux.

It turned out that this directory, for some reason, wasn't created when dbus package was installed. So, I created that directory and disabled SELinux in /etc/sysconfig/selinux.

Next problem was that Firefox didn't want to start for some unknown reason. I have several different profiles and firefox would stuck at profile selection dialog box. But, this was something transient because after several tries it continued to work without any problems.

VMWare

First, I'm using VMWare Workstation 9.0.1. So, this text applies to that version. VMWare couldn't compile kernel modules, so I applied this patch. Simply unpack it to some temporary directory and run bash script. During the compilation process, there are a lot of warnings like this one:

/tmp/modconfig-ZB7ihE/vsock-only/linux/vsockPacket.h:113:4: note: in expansion of macro ‘ASSERT_ON_COMPILE’
    ASSERT_ON_COMPILE(sizeof (VSockPacket) == 56);
    ^
/tmp/modconfig-ZB7ihE/vsock-only/./shared/vmci_iocontrols.h: In function ‘VMCIVA64ToPtr’:
/tmp/modconfig-ZB7ihE/vsock-only/./shared/vm_assert.h:320:20: warning: typedef ‘AssertOnCompileFailed’ locally defined but not used [-Wunused-local-typedefs]

But, despite those warnings, modules compiled and I managed to start VMWare.

Then, I had a problem with entering serial key. When I pressed button Enter key... nothing happened. I entered it via a command line, like this:

/usr/lib/vmware/bin/vmware-vmx-debug --new-sn XXXXXXXXXXXXXXXXXXXXXXXX

After that, everything seemed to work. By the way, here is a very good page I used to get VMWare working.