The last time I tried to use Yum to upgrade from one version of Fedora to another it didn’t exactly work out. This time I thought I would try it out first in a virtual machine. If something goes wrong just delete the VM.
When trying something like this, you should make sure that the keepcache setting in yum.conf is switched on. Otherwise if something goes wrong you will find yourself having to download the hundreds of megabytes of files all over again.
In my case just typing ‘yum upgrade’ resulted in a long list of dependency matches and a total suggested download of 1.1 Gb. That’s a lot smaller than downloading the whole DVD but I thought I would upgrade just the essentials. In this case the essentials was just xorg.conf (because I want to be able to use the seamless mode in VirtualBox).
Once the deps were resolved for upgrading xorg, 232 packages need to be downloaded and their total size is 374MB. I wasn’t excepting to smooth sailing and it wasn’t long before I ran into rough weather.
Transaction Check Error:
file /usr/lib/xorg/modules/drivers/r128_drv.so from install of xorg-x11-drv-r128-6.8.0-1.fc10.i386 conflicts with file from package xorg-x11-drv-ati-6.8.0-12.fc9.i386
file /usr/share/man/man4/r128.4.gz from install of xorg-x11-drv-r128-6.8.0-1.fc10.i386 conflicts with file from package xorg-x11-drv-ati-6.8.0-12.fc9.i386
file /etc/pki/tls/certs/ca-bundle.crt from install of ca-certificates-2008-7.noarch conflicts with file from package openssl-0.9.8g-6.fc9.i686
file /usr/lib/xorg/modules/drivers/mach64_drv.so from install of xorg-x11-drv-mach64-6.8.0-1.fc10.i386 conflicts with file from package xorg-x11-drv-ati-6.8.0-12.fc9.i386
Usually when faced with problems like this, my approach is to simply remove the offending rpms (keeping my fingers crossed of course). I was reluctant to remove the openssl RPM is more than likely to break yum. So I just removed the others and asked yum to have another go. Obviously this is where using the keepcache option comes in handy. Real handy.
When I ran yum again it wanted to download another 26MB. In for a penny , in for a pound. Even then the update still failed because of the conflict with openssl. I reluctantly decided to update openssl before continuing. There are countless programs and libraries linked to openssl the chances are very high that ‘yum update openssl’ will lead to vicious cycle of dependency resolution with the end result of a total download that is as big as what you would see with just plain ‘yum upgrade’
Fortunately that didn’t happen. Only three packages were updated as a result of the ‘yum update openssl’ command. Then in once again typed ‘yum groupupdate “X Window System”‘ and this time the transactions started without any time being spent on downloads.
During the transaction another error appeared on the screen (but yum didn’t bail out because of it)
/sbin/new-kernel-pkg: line 287: /sbin/depmod: Permission denied
/sbin/mkinitrd: line 1677: /sbin/depmod: Permission denied
“/sbin/depmod -a 2.6.27.5-109.fc10.i686″ failed.
mkinitrd failed
So I thought to run /sbin/depmod -a 2.6.27.5-109.fc10.i686 manually and to keep my fingers crossed and hope there wouldn’t be any boot up problems. Further on , yum did run into what appears to be a more serious error.
Traceback (most recent call last):
File “/usr/sbin/yum-complete-transaction”, line 198, in <module>
util = YumCompleteTransaction()
File “/usr/sbin/yum-complete-transaction”, line 114, in __init__
self.main()
File “/usr/sbin/yum-complete-transaction”, line 184, in main
if self.doTransaction() == 0:
File “/usr/share/yum-cli/cli.py”, line 464, in doTransaction
resultobject = self.runTransaction(cb=cb)
File “/usr/lib/python2.5/site-packages/yum/__init__.py”, line 846, in runTransaction
self.plugins.run(‘posttrans’)
File “/usr/lib/python2.5/site-packages/yum/plugins.py”, line 176, in run
func(conduitcls(self, self.base, conf, **kwargs))
File “/usr/lib/yum-plugins/refresh-packagekit.py”, line 37, in posttrans_hook
packagekit_iface.StateHasChanged(‘posttrans’)
File “/usr/lib/python2.5/site-packages/dbus/proxies.py”, line 68, in __call__
return self._proxy_method(*args, **keywords)
File “/usr/lib/python2.5/site-packages/dbus/proxies.py”, line 140, in __call__
**keywords)
File “/usr/lib/python2.5/site-packages/dbus/connection.py”, line 597, in call_blocking
message.append(signature=signature, *args)
TypeError: More items found in D-Bus signature than in Python arguments
But that occurred in the cleanup stage. There were 443 items in the transaction (including installs, updates and removes). The above error occurred after the 443rd item. So now I am not sure if the system has been succesfully updated (the error can be ignore) or the update has failed. Well I found out that the update had failed when I tried to reboot – the new kernel didn’t show up in the grub boot menu.
my solution for dealing with SELinux is simple. Disable it completely.