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.