After an upgrade from FC2 to FC3t1, for any package with both i386 and x86-64 versions installed, only the x86-64 version of the package was upgraded.
I wonder if this is the always prefer 64 bit in a transaction. Quick test, for a biarch package that you care little about (and has no package requiring it) roll both back to an earlier version (or update to a later rahwide version if available) rpm --qf '%{name}-%{version}-%{release}.%{arch}\n' -q testpackage rpm -Uvh testpackage.i386.rpm testpackage.x86_64.rpm rpm --qf '%{name}-%{version}-%{release}.%{arch}\n' -q testpackage
Unfortunately, the only biarch packages I have installed is glibc, and that's because grub requires it, and that obviously has things requiring it. So, no rollbacks/upgrades possible in that scenario. The reason for this is that I got bit by a bunch of biarch problems with FC2 and just removed all i386 packages (except for glibc, which the x86-64 version of grub requires). Now that I think about it, I know this also happened with the FC2 versions of anaconda & rpm, which predates the "always prefer Elf64" changes. After the FC2 upgrade, I remember that freetype.x86_64 had been upgraded and but not freetype.i386, and this led me to notice that none of the other i386 packages had been upgraded as well. (I rebuild freetype with the TrueType bytecode interpreter enabled, and the upgrade resulted in the 64-bit apps using ugly fonts while the 32-bit apps still displayed nicely hinted fonts.) Sorry for the delayed bug report.
Please attach /var/log/rpmpkgs /var/log/rpmpkgs.1 and the anaconda logs /root/upgrade.log.*
sorry /root/upgrade.log*
Created attachment 104108 [details] upgrade.log, rpmpkgs, rpmpkgs.1 Here you go. upgrade.log.syslog was empty, so I omitted it.
Can not confirm that from the logs started with: freetype-2.1.7-4.njm.1.x86_64.rpm freetype-demos-2.1.7-4.njm.1.x86_64.rpm freetype-devel-2.1.7-4.njm.1.x86_64.rpm freetype-utils-2.1.7-4.njm.1.x86_64.rpm update did Upgrading freetype-2.1.9-1.x86_64. Upgrading freetype-devel-2.1.9-1.x86_64. Upgrading freetype-demos-2.1.9-1.x86_64. Upgrading freetype-utils-2.1.9-1.x86_64. reporting The following packages were available in this version but NOT upgraded: freetype-2.1.9-1.i386.rpm Then you rebuilt freetype-2.1.9-1.njm.1.x86_64.rpm freetype-demos-2.1.9-1.njm.1.x86_64.rpm freetype-devel-2.1.9-1.njm.1.x86_64.rpm freetype-utils-2.1.9-1.njm.1.x86_64.rpm freetype-2.1.7-4.njm.1.x86_64.rpm Are you 100% positive you had freetype.i386 installed?
I did when I upgraded from FC1 to FC2. Since then, I removed all i386 packages except glibc and libgcc. (All that rambling about freetype was me remembering that I had this exact same problem with the FC1 to FC2 upgrade, prior to the "always prefer Elf64" changes to RPM.)
I'm just trying to clarify the bug details to a specific case, you state: Upgrade from FC2 to FC3T2 - any i386 package not upgraded. Pre upgrade (rpm: glibc-devel-2.3.3-27.i386.rpm libgcc-3.3.3-7.i386.rpm upgrade log: Upgrading glibc-devel-2.3.3-53.x86_64. but says not doing this glibc-devel-2.3.3-53.i386.rpm Post upgrade (rpmpkgs): glibc-devel-2.3.3-54.i386.rpm glibc-devel-2.3.3-54.x86_64.rpm Did you install glibc-devel.i386 manually after the upgrade?
Yes, I manually updated glibc.i386, glibc-devel.i386, and libgcc.i386.
*** Bug 133820 has been marked as a duplicate of this bug. ***
I've created a fix for this on HEAD and will be out on next anaconda roll - if you are available to test let me know here or better on irc.freenode.net #fedora-bugweek nick: nasrat and I can supply an updated python file for you to test.
Could you please attach the fix here? I can give it a try on ia64 and x86-64.
Created attachment 104520 [details] findpackageset Assuming you are doing exploded nfs tree - create RHupdates/ at top of the rawhide/fc3tX tree and put the attached python file in. eg: . |-- Fedora | |-- RPMS | `-- base |-- RHupdates |-- images More details about updates are available in /usr/share/anaconda-.../install-methods.txt (where ... is anaconda version).
Created attachment 104555 [details] Python trace I need this patch --- findpackageset.py.rhel4 2004-09-29 12:02:03.000000000 -0700 +++ findpackageset.py 2004-09-29 16:21:49.426650553 -0700 @@ -94,6 +94,8 @@ def findpackageset(hdrlist, dbPath='/'): hdlist = availDict.values() + ts = rpm.TransactionSet(dbPath) + # loop through packages and find ones which are a newer # version than what we have for ( name, arch ) in instDict.keys(): to avoid the crash on RHEL 4 b1. But now I got this Python crash
Thanks for catching that. I overy entusiastically refactored it out whilst still using it in obsolete handling. Fix in anaconda 10.0.3.8-1 The trace seems unrelated to this bug in particular - if it's reproducible without the RHupdates on latest rawhide please file a seperate bug. I'll try and reproduce locally here.
Created attachment 104579 [details] Simple testcase not requiring install A simple test case that you can run with anaconda installed from rawhide today (10.0.3.8-1) It supports using a hdlist or generating one from a dir of rpms on the fly test-findpackageset.py --hdlist ./hdlist
The modified findpackageset.py works for me on x86-64. I created a new boot.iso with the modified initrd.img which has findpackageset.py under /tmp/updates. I used the new boot.iso with the original RHEL 4 beta 1 ISOs.
Inspected twaugh's upgrade logs and rpm -qa before/after: snippet: Upgrading howl-libs-0.9.6-6.i386. Upgrading howl-libs-0.9.6-6.x86_64. Upgrading ORBit2-2.12.0-3.i386. Upgrading ORBit2-2.12.0-3.x86_64. Upgrading libbonobo-2.8.0-2.i386. Upgrading libbonobo-2.8.0-2.x86_64. ... biarch seems happy.