Bug 134943 - anaconda will not install i386 packages on ia64, rpm will.
anaconda will not install i386 packages on ia64, rpm will.
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: anaconda (Show other bugs)
3.0
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-07 09:46 EDT by Richard Nuttle
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-07 10:32:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard Nuttle 2004-10-07 09:46:20 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922

Description of problem:
I am trying to get i386 and ia64 versions of the same package to
install on ia64 to allow for a compatible runtime environment with our
i[3-6]86 developed packages. When kickstart starts installing packages
it mysteriously skips over some i[3-6]86 versions of packages while
installing others successfully. Anaconda produces no unusual output on
alt-f3 or alt-f4, the install.log has no indication that the i[3-6]86
packages which are not installing are ever processed. There are some
failures in the install.log for certain i[3-6]86 packages but they
appear to be related to unsatisfied dependencies from the previous
i[3-6]86 packages which mysteriously did not install. We use http as
our install method for kickstart and apache logs indicate that
anaconda never attempted to retrieve the packages in question. I have
a seemingly valid pkgorder file, and create seemingly valid hdlists
I've used different versions of genhdlist (rpm-4.2.1/anaconda-9.1.1 on
solaris/sparc, anaconda-9.1.3-RHEL.3 on RHEL3 U3 x86 and ia64), all
with the same result) The following packages do not install:

libgcc-3.2.3-42.i386.rpm
krbafs-1.1.1-11.i386.rpm
libattr-2.2.0-1.i386.rpm
libacl-2.2.3-1.i386.rpm
attr-2.2.0-1.i386.rpm
acl-2.2.3-1.i386.rpm
libjpeg-6b-30.i386.rpm
libobjc-3.2.3-42.i386.rpm
libstdc++-3.2.3-42.i386.rpm
libtermcap-2.0.8-35.i386.rpm
popt-1.8.2-10.i386.rpm
tcl-8.3.5-92.2.i386.rpm
libpng-1.2.2-25.i386.rpm
libtiff-3.5.7-13.i386.rpm
bash-2.05b-29.0.3.i386.rpm
libgcj-3.2.3-42.i386.rpm
cups-libs-1.1.17-13.3.12.i386.rpm
pam-0.75-58.i386.rpm
pam_krb5-1.73-1.i386.rpm
tk-8.3.5-92.2.i386.rpm

yet both the i[3-6]86 and ia64 versions appear in the pkgorder file,
and an emacs or strings of the resulting hdlists shows header
information for both archs. I checked the rpm tags in the headers for
each ia64 and i[3-6]86 packages and did not notice any obvious
differences other than file sizes, build times, etc.

Looking over the anaconda source, I cannot find any obvious reason why
this is happening. 

After the machine has kickstarted I can install the packages manually
using rpm.

The machinery which generates the comps file for our builds lists
packages with multiple architechtures multiple times, but this has not
appeared to bother anaconda in the past, and some packages which are
listed multiple times and have multiple archs are installed as expected.

I can provide the pkgorder file, a snapshot of the build tree (with
our local packages removed), the install.log, the resulting hdlists,
comps, and pkgorder files (again local packages removed) on request.


Version-Release number of selected component (if applicable):
9.1.3-RHEL.3

How reproducible:
Always

Steps to Reproduce:
1. run gehndlist --withnumbers --hdlist <hdlist> --fileorder
<pkgorderfile> <tree>
2. kickstart the machine
3. certain i[3-6]86 packages do not get installed.
    

Actual Results:  none of these get installed: 

libgcc-3.2.3-42.i386.rpm
krbafs-1.1.1-11.i386.rpm
libattr-2.2.0-1.i386.rpm
libacl-2.2.3-1.i386.rpm
attr-2.2.0-1.i386.rpm
acl-2.2.3-1.i386.rpm
libjpeg-6b-30.i386.rpm
libobjc-3.2.3-42.i386.rpm
libstdc++-3.2.3-42.i386.rpm
libtermcap-2.0.8-35.i386.rpm
popt-1.8.2-10.i386.rpm
tcl-8.3.5-92.2.i386.rpm
libpng-1.2.2-25.i386.rpm
libtiff-3.5.7-13.i386.rpm
bash-2.05b-29.0.3.i386.rpm
libgcj-3.2.3-42.i386.rpm
cups-libs-1.1.17-13.3.12.i386.rpm
pam-0.75-58.i386.rpm
pam_krb5-1.73-1.i386.rpm
tk-8.3.5-92.2.i386.rpm


Expected Results:  at least some of them should install :-)

Additional info:

all packages that fail are in the hdlists for both ia64 and i[3-6]86
archs, and are supposed to be installed for both archs.
Comment 1 Jeremy Katz 2004-10-07 10:05:26 EDT
How are you specifying that the non-primary arch versions of the
packages should be installed?
Comment 2 Richard Nuttle 2004-10-07 10:17:11 EDT
The rpm headers show up in the ordered hdlists and the comps file has 
dual <packagereq> entries for each package, i.e.

<group>
<id>core</id>
<name>Core</name>
...
<packagereq type="mandatory">bash</packagereq>
<packagereq type="mandatory">bash</packagereq>
....
</group>

<group>
<id>base</id>
<name>Base</name>
....
<grouplist>
<groupreq>core</groupreq>
</grouplist>
...
</group>

Our ks.cfg just says
%packages
@Base

Let me know if you need more info.
Comment 3 Jeremy Katz 2004-10-07 10:32:49 EDT
Ermm, that isn't going to work at all :)  Just listing the package
more than once in the comps group does nothing. 

You need to add a group that's tagged biarchonly (see
compat-arch-support, for example) and then ensure that group gets
installed.

Note You need to log in before you can comment on or make changes to this bug.