Removing duplicate i386 packages on a x86_64 system after a Pre-Upgrade from FC8-FC10

[timblack]

I recently upgraded my x86_64 system from FC8 to FC10 using Pre-Upgrade. (related blog link) It appears that the upgrade process installed a steaming pile of i386 packages that are duplicates of existing x86_64 packages. I now get update errors because of this package clash.

I have searched the fora and the most progress I've been able to make so far is:

I apparently had 8 unfinished yum transactions so I did yum-complete-transaction 8 times and have no more incomplete transactions.

The output of package-cleanup --dupes is not very helpful:

[tim@servy ~]$ sudo package-cleanup --dupes 
Setting up yum
Loaded plugins: refresh-packagekit

Yet I still get transaction errors when I run updates via synaptic. It checks dependencies and downloads everything and errs when testing changes. This is the error it gives at the moment:

Test Transaction Errors:   file /etc/gconf/schemas/gweather.schemas from install of libgweather-2.24.2-1.fc10.x86_64 conflicts with file from package gnome-applets-1:2.20.1-1.fc8.i386
  file /usr/bin/panel-test-applets from install of gnome-panel-devel-2.24.3-2.fc10.i386 conflicts with file from package gnome-panel-2.20.3-2.fc8.i386
  file /etc/gconf/schemas/charpick.schemas from install of gnome-applets-1:2.24.3.1-1.fc10.x86_64 conflicts with file from package gnome-applets-1:2.20.1-1.fc8.i386
  file /etc/gconf/schemas/cpufreq-applet.schemas from install of gnome-applets-1:2.24.3.1-1.fc10.x86_64 conflicts with file from package gnome-applets-1:2.20.1-1.fc8.i386
  file /etc/gconf/schemas/drivemount.schemas from install of gnome-applets-1:2.24.3.1-1.fc10.x86_64 conflicts with file from package gnome-applets-1:2.20.1-1.fc8.i386
  file /etc/gconf/schemas/geyes.schemas from install of gnome-applets-1:2.24.3.1-1.fc10.x86_64 conflicts with file from package gnome-applets-1:2.20.1-1.fc8.i386
  file /etc/gconf/schema...

Any ideas what is going on, or suggestions for what I might do next to solve the problem?

Thanks!
T

[Hlingler]

It appears that the simplest thing to try is:
su
yum remove gnome-applets-2.20.1-1.fc8.i386 gnome-panel-2.20.3-2.fc8.i386

V

P.S. If 'package-cleanup --dupes' returns no output (except a new prompt), then like any "well-behaved" *NIX program, it has succeeded (i.e.: found no dupes). Note that equivalent 32-bit and 64-bit packages are permitted on Fedora 64-bit OS, and not considered duplicates.

[jpollard]

You might try to upgrade the packages rather than update.

I haven't had this issue since I tend to do re-installs...

But an upgrade from 8 to 10 just might confuse things.

if that is what you did, are you trying to switch from 32 bit to 64 bit systems? or were you always 64bit?

If always 64 bit, then try a "yum remove gnome-applets-1:2.20.1-1.fc8.i386". If that clears the problem, then you
could repeat for the other packages. If you don't want any 32 bit packages you might try "yum remove '*.i386'".

With only 6 such packages causing problems, manually doing them isn't unreasonable.

[timblack]

OK, thanks for the replies! So package-cleanup says I have no duplicate packages, but there sure are a lot of packages that i have both i386 and x86_64 versions installed.

I was hoping for an automatic way to do this, as I suspect there are dozens if not hundreds of packages with the same problem. (based on package errors I saw during pre-upgrade) For now, I'll just remove the offending i386 packages in the most recent error and hope the problem goes away.

BTW, my install was always 64-bit.

[timblack]

So I removed gnome-applets-1:2.20.1-1.fc8.i386 and gnome-panel-2.20.3-2.fc8.i386 (which removed a bunch of other pkgs) and am now doing a yum upgrade. I suspect there's a better way to test for conflicts than this, bc I've got 800+ pkgs to update, so it's going to download them all before the test phase where it would report conflicts. I guess it can't detect conflicts before downloading them purely based on their arch bc there are cases where you want a pkg installed for multiple archs. OK. For now, I'll just wait and see if I get any errors...

[jpollard]

Multiple archs are possible (64 bit/32 bit). The ones you got may have occurred because some features in in one
may have moved into another. The intermediate upgrade to Fedora 9 may have handled that.

[Hlingler]

I suspect there's a better way to test for conflicts than this, bc I've got 800+ pkgs to update, so it's going to download them all before the test phase where it would report conflicts. I guess it can't detect conflicts before downloading them purely based on their arch bc there are cases where you want a pkg installed for multiple archs. OK. For now, I'll just wait and see if I get any errors...

I know of no "better way" to test for conflicts such as you saw, prior to download. Dependencies are checked, of course, based on package header info, but the file manifest is unknown to YUM until package(s) is downloaded, so such file duplication conflicts will remain unknown until transaction test phase.

To reduce download size, and save dwindling hairline/patience, you could reduce transaction to one or two groups at a time, e.g.:
yum --obsoletes groupupdate "X Window System"

Run 'yum grouplist' for list of installed (and available) groups. Pick small groups first (guess).

V

[timblack]

Thanks V! Updating by group is much less painful!

Still, it would be nice if Pre-Update didn't advertise as supporting the leapfrogging of releases, e.g. FC8->FC10. It's debatable whether what I'm doing now is less pain than a fresh reinstall...

...Anyway, so far I've removed about half of the offending packages, and performed the corresponding updates, but I came across a conflict that I've not been able to resolve:

sudo yum --obsoletes -y groupupdate "GNOME Software Development" creates the following error:

Transaction Check Error:
file /usr/share/gtk-doc/html/pango/PangoMarkupFormat.html conflicts between attempted installs of pango-devel-1.22.3-1.fc10.x86_64 and pango-devel-1.22.3-1.fc10.i386
file /usr/share/gtk-doc/html/pango/pango-querymodules.html conflicts between attempted installs of pango-devel-1.22.3-1.fc10.x86_64 and pango-devel-1.22.3-1.fc10.i386

but when I try to remove pango-devel-1.22.3-1.fc10.i386, I get:

[~]$ sudo yum remove pango-devel-1.22.3-1.fc10.i386
Loaded plugins: allowdowngrade, refresh-packagekit
Setting up Remove Process
No Match for argument: pango-devel-1.22.3-1.fc10.i386
Package(s) pango-devel-1.22.3-1.fc10.i386 available, but not installed.
No Packages marked for removal

So I'm guessing Pre-Upgrade failed to install pango. Pango has hundreds of dependencies on my system, so I'm not about to yum remove pango. Any suggestions?

[Hlingler]

Try excluding all *.i386:
sudo yum --obsoletes -y groupupdate "GNOME Software Development" -x *.i386

If that fails, try first:
sudo yum remove pango-devel.i386

then repeat your above command.

V

[timblack]

Thanks! OK, I tried:
sudo yum --obsoletes -y groupupdate "GNOME Software Development" -x *.i386

and got some dependency errors and the suggestion to use the --skip-broken option, which I then tried:
sudo yum --obsoletes --skip-broken -y groupupdate "GNOME Software Development" -x *.i386

This gave me a loooong list of "Transaction Check Errors", so I yum removed the listed offending i386 packages. A few cycles of yum upgrade/remove later and I've now got a system with NO package management ERRORS! :-)

Now I'm going to start the process of cleaning up my repository list and pruning unneeded packages...

Thanks!

[timblack]

So all my yum errors are gone and I thought I was working with a clean slate. But upon reboot I noticed something is wrong with DNS. Check this out:

I can ping www.yahoo.com.

nslookup www.yahoo.com provides multiple name resolutions.

Browsing to www.yahoo.com in firefox or links gives a "host not found" error. Typing the ip addr from nslookup works fine in both firefox and links.

Very strange. Haven't seen this before.

I read many reports of ipv6 causing this behavior. I didn't suspect this was the problem, bc it extended to links as well as firefox. I tried it anyway and it worked. I.e. In firefox, I went to about:config and set network.dns.disableipv6 = true, restarted firefox et voila!

I suspect links would start working if I cared enough to figure out how to configure it to turn off ipv6 support.

OK, so now it works, but does anyone know why? What's the fun in being on the bleeding edge if you've got all the bloody features disabled?

Thanks,
Tim

[Hlingler]

If you are now satisfied that the OS upgrade is complete, I would suggest that you run the following commands to test for problems:
sudo package-cleanup --dupes
sudo package-cleanup --problems

Purge old dupes, and fix dependency problems (if any) - note once again that no results = no dupes/problems, and that both 32-bit and 64-bit packages may co-exist (but are supposed to be same version-release). Then find stale packages that have not been updated for whatever reason, and assess:
sudo package-cleanup --orphans | sort
rpm -qa | grep -v fc10 | sort

If you find many left-overs from previous release(s), try:
sudo yum reinstall <insert-base-package-name-without-ARCH-or-"fcxx">

to (try to) bring it up to latest F10. Note that many packages may not have been upgraded between F9 and F10 (due to no need), so the "orphans" output may be more informative. Be very careful when deciding what to do about such "orphans".

V

[timblack]

Hey, V, thanks for hanging with me! I hope to get to testing for stale packages soon, but for now... looks like no yum package problems:

[~]$ sudo package-cleanup --dupes
Setting up yum
Loaded plugins: refresh-packagekit
[~]$ sudo package-cleanup --problems
Setting up yum
Loaded plugins: refresh-packagekit
Reading local RPM database
Processing all local requires
No problems found

However, there is now a yum dns problem:

[~]$ sudo yum update
Loaded plugins: allowdowngrade, refresh-packagekit
http://linuxdownload.adobe.com/linux/i386/repodata/repomd.xml: [Errno 4] IOError: <urlopen error (-2, 'Name or service not known')>
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: adobe-linux-i386. Please verify its path and try again

However, I can access this URL (http://linuxdownload.adobe.com/linux...ata/repomd.xml) via firefox after turning off ipv6 support in dns. (per my last post)

Note: yum could obviously find repos before the reboot. My belief is that one of the base pkgs I just updated has ipv6 support in dns, which is not working on my system for some reason. Any idea how to configure this?

Thanks

[Hlingler]

Try:
yum clean all

and repeat. If problem persists, then this must be a separate DNS issue. In which case, I suggest that you start a new thread to address. I personally know little about DNS.

V

[jpollard]

You might check the validity of your /etc/resolv.conf file.

It may have gotten damaged (though unlikely)