The never ending problems with Fedora Updates.

2009 June 19 at 02:14 » Tagged as :video, ctc,

Updated my media server which was previously running Fedora 10 to Fedora 11. A whole floor separates this from my usual perch. So to avoid, running up and downstairs I did a remote install using VNC. The installation guide suggests starting up with vncconnect=hostname as a command line parameter. When you do that you need to start the VNC client on another computer to listen to an incoming connection. In other words we are seeing a reversal of the traditional client server roles (FedoraProject). But it didn't quite happen that way; The installer did not connect to my VNC client (yes, IPTables was off) but it did start up a VNC server and did allow a connection from my client. The display was not the only thing that was sent over the network. All the RPMS were too. Installing from DVDs is painfully slow, it's much faster to install over the network. So I mounted the ISO (downloaded with JIGDO) under /var/www/html/ so that the installer can fetch the files from there. It didn't take too long to update nearly 1700 rpms but the post installation process seemed to take for ever and at one point I wasn't even sure if it had hung. As usual it messed up grub. Every time fedora is updated, you need to boot into rescue mode and do a 'grub-install' to fix it. Now you wouldn't expect a system that was updated through VNC to refuse to allow you to connect to it after the install stallation  is complete but this one did:
IMSETTINGS_DISABLE_DESKTOP_CHECK: DBUS_SESSION_BUS_ADDRESS: unix:abstract=/tmp/dbus-zju2U6PGN3,guid=3ef6632ab456fc90910b2b4a375371 GTK_IM_MODULE: gtk-im-context-simple QT_IM_MODULE: xim XMODIFIERS: @im=none IMSETTINGS_MODULE: none IMSETTINGS_INTEGRATE_DESKTOP: yes ** (gnome-session:2515): WARNING **: Cannot open display:
This is because the default VNC software has changed from Fedora 10 to Fedora 11. (DSLReports Forum) The solution was to manually install tigerVNC. The usual course of action after an installation or an update is to follow it up with an 'yum update' during this process, I found a lot of dependency problems. The first complaint was that yum couldn't find some RPMS which were supposed to have been installed.

--> Missing Dependency: libMagickCore.so.1()(64bit) is needed by package xine-lib-1.1.16.3-18.fc10.x86_64 (atrpms) xine-lib-1.1.16.3-18.fc10.i386 from atrpms has depsolving problems --> Missing Dependency: libcdio.so.7(CDIO_7) is needed by package xine-lib-1.1.16.3-18.fc10.i386 (atrpms) PIL-1.1.6-9.fc10.x86_64 from atrpms has depsolving problems

...Error: Missing Dependency: libodbc.so.1()(64bit) is needed by package 1:asterisk-1.4.25.1-78.fc10.x86_64 (atrpms) Error: Missing Dependency: /usr/bin/python2.5 is needed by package PIL-1.1.6-9.fc10.x86_64 (atrpms) Error: Missing Dependency: libcdio.so.7(CDIO_7)(64bit) is needed by package xine-lib-1.1.16.3-18.fc10.x86_64 (atrpms) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest

Opinion is devided about the usefulness of AtRpms, I first started using it when RPMFusion was not around so I had no choice but this seems like a good time to discontinue it. Disabling the atrpms repo didn't do any magic either.  Another different set of dependency problems crept up.

---> Package openbios-common.noarch 0:1.0-1.fc set to be updated ---> Package plymouth-plugin-two-step.x86_64 0:0.7.0-0.2009.05.15.1.fc set to be updated ...

--> Missing Dependency: libmikmod.so.2()(64bit) is needed by package 1:xmms-libs-1.2.11-36.99_8.fc8.x86_64 (installed) mythmusic-0.21-201.fc10.x86_64 from installed has depsolving problems --> Missing Dependency: libfaad.so.0()(64bit) is needed by package mythmusic-0.21-201.fc10.x86_64 (installed) .... Error: Missing Dependency: libfaad.so.0()(64bit) is needed by package mythmusic-0.21-201.fc10.x86_64 (installed) Error: Missing Dependency: libpri.so.1.0()(64bit) is needed by package 1:asterisk-1.4.20-63.fc9.x86_64 (installed) Error: Missing Dependency: libmikmod.so.2()(64bit) is needed by package 1:xmms-libs-1.2.11-36.99_8.fc8.x86_64 (installed) --skip-broken doesn't really work. Even when it does work, what it really does is to sweep the whole mess under the carpet only to resurface later. These dependency resolution problems were unending. I uninstalled and reinstalled all kinds of packages countless times to whittle down this dependency problems. Most of the depsolving problems seem to be related to vlc, mythtv and other multimedia packages. Strangely some of the installed dependencies had an f9 tag to it. Despite my best efforts the f9-f10 update apparently had left behind a lot of garbage. I had trouble with an RPM key enpassant.

warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 signature: NOKEY, key ID 8fcff4da rpmfusion-free/gpgkey                                                                                                                                             | 1.7 kB     00:00 Public key for avidemux-cli-2.4.4-6.fc.x86_64.rpm is not installed The key file had strangely gone missing and the 'repo rpm' had to be downloaded and reinstalled before I could go onto the next round of sorting out the dependencies. After many such rounds I finally arrived at a stage where yum was trying to install some 960 MB of updates.

rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

Now yum was reporting conflicts for kdeutils-6:4.2.3-1.fc.i586 and kdeutils-6:4.2.3-1.fc.x86_64 - they are both the same package but different architectures and really shouldn't be installed together. What's happening now is that some of the older f7, f8 and f9 rpms 'survivors' were 32 bit versions and somehow or other yum got it into it's head that this is 32 bit system. After another dozen or so rounds of 'rpm -e', 'yum remove', 'yum install' and 'yum updates'. Finally got to a stage where the system update could proceed but only after a few more enpassants. Some of which were caught by using the --noscripts parameter to rpm

ERROR with rpm_check_debug vs depsolve: kdegraphics-libs is needed by (installed) kdegraphics-extras-7:3.5.9-1.fc8.i386 kdegraphics-libs is needed by (installed) kdegraphics-extras-7:3.5.9-1.fc8.i386 Complete! (1, [u'Please report this error in http://yum.baseurl.org/report'])

After all these cleanups I found that nearly 2GB of disk space had been freed!