Bug 349701 - mulitlib conflicts in composing install media
mulitlib conflicts in composing install media
Product: Fedora
Classification: Fedora
Component: pungi (Show other bugs)
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-10-23 18:35 EDT by John Reiser
Modified: 2013-01-09 20:42 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-15 14:41:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/usr/share/pungi/f8-fedora.ks (3.24 KB, text/plain)
2007-10-23 21:29 EDT, John Reiser
no flags Details

  None (edit)
Description John Reiser 2007-10-23 18:35:21 EDT
Description of problem: Something peculiar is going on with multilib in pungi
for x86_64.  One hint is given by the logfile sizes:
  -rw-r--r-- 1 root root 1942554 2007-10-23 07:27 i386.log
  -rw-r--r-- 1 root root 8192450 2007-10-23 14:30 x86_64.log
where the x86_64 log is four times as large as the i386 log.  Looking more closely:
  grep "Matched glibc " x86_64.log  | \
  sed s'/ to require.*//'  | \
  sort  |  uniq -c
shows that six different glibc are being used instead of only three:
     62 yum.verbose.YumBase.DEBUG: Matched glibc - 2.6.90-21.i386
     62 yum.verbose.YumBase.DEBUG: Matched glibc - 2.6.90-21.i686
     55 yum.verbose.YumBase.DEBUG: Matched glibc - 2.6.90-21.x86_64
    310 yum.verbose.YumBase.DEBUG: Matched glibc - 2.7-2.i386
    310 yum.verbose.YumBase.DEBUG: Matched glibc - 2.7-2.i686
    275 yum.verbose.YumBase.DEBUG: Matched glibc - 2.7-2.x86_64

Version-Release number of selected component (if applicable):

How reproducible: always

Steps to Reproduce:
1. create install DVD using recipe from EXAMPLES on pungi man page:
"pungi -c /usr/share/pungi/f8-fedora.ks --destdir=/data/Fedora8 --name Fedora
--ver 8 --discs=4"
2. On successive days, accumulate more packages in the pungi cache by "rm -rf
/data/Fedora8" and then re-run #1.
3. Examine /data/Fedora8/logs/x86_64.log  for which glibc versions were matched.
Actual results: Both glibc-2.6.90-21 and glibc-2.7-2 are matched for i386, i686,
and x86_64 (six cases in all).

Expected results: 
All glibc versions should be 2.6.90-21, or all should be 2.7-2  (three cases in

Additional info: Could mismatching the PT_INTERP (ld-linux.so.2 -> ld-2.7.so)
account for the problem of bug #349131 "exec of anaconda failed: No such file or
directory" ?
Comment 1 Jesse Keating 2007-10-23 20:20:36 EDT
I'm confused, if you're using the f8 config, you should be pointing at a rawhide
repo which only has one copy of any given build.  How is the yum object possibly
finding more than one copy?  We use what we find in yum repos to determine what
goes into the media, and if there happens to be a download of it in the cache
after we determine what we want we'll take it.  What repos are you pointing at?
Comment 2 John Reiser 2007-10-23 21:24:29 EDT
I will attach the actual .ks file.  It shows:
repo --name=rawhide 
repo --name=rawhide-source 
Again, the acutal command line is:
  pungi -c /usr/share/pungi/f8-fedora.ks --destdir=/data/Fedora8 --name Fedora
--ver 8 --discs=4
which is the same as the EXAMPLE in the pungi manual page, excep that "
--discs=4" has been added because I'm also testing CDs as well as DVD.

Speculation: could the problems be caused by a bad or out-of-sync repo?  Each
day I "rm -rf /data/Fedora8" then re-run the pungi command.

Comment: it seems to me that it would be an excellent idea to keep track of the
source of each .rpm and control file.  Perhaps put "DATE=nnnnnnnnn  URL=..." as
extended attributes.  Then there might be some chance to figure out how things
went wrong.
Comment 3 John Reiser 2007-10-23 21:29:07 EDT
Created attachment 235741 [details]

Kickstart file.  Based on pungi-1.1.6-1.fc8.  Modified to give 700,000,000 byte
CDs, and to comment out "@ <language>-support" lines, and to add
'policycoreuntils' explicitly (attempt to workaround bug #343861 "can't load
policy: No such file or directory" by anaconda during initial load at beginning
of install.
Comment 4 Jesse Keating 2007-10-23 21:48:22 EDT
Ok, perhaps the mirror you're getting back from the mirrorlist url is whacky. 
Given that most things should be in your cache already, what happens if you
point directly at
http://download.fedora.redhat.com/pub/fedora/linux/development/x86_64/os ?
Comment 5 John Reiser 2007-10-24 01:48:18 EDT
What's the syntax for a specific source repo?  Using:
 repo --name=rawhide
 repo --name=rawhide-source 
then I get:
Pungi.Gather:INFO: Finished downloading packages.
Pungi.Gather:INFO: Running /usr/bin/xsltproc --novalid -o
/data/Fedora8/work/x86_64/Fedora-8-comps.xml /usr/share/pungi/comps-cleanup.xsl
 Error: Cannot find a source rpm for pcmciautils-014-11.fc8
even though firefox can see

Meanwhile, I tried again using the original --mirrorlist syntax (and no
--baseurl), and produced a DVD that booted and installed OK.
Comment 6 Jesse Keating 2007-10-24 09:31:10 EDT
Your second url should be:

repo --name=rawhide-source
Comment 7 John Reiser 2007-10-24 12:14:33 EDT
Thank you, that second url works, and the DVD installs OK.  Tested with this
morning's rawhide (Wed.Oct.24.)

So, it looks like the mirroring system doesn't behave like I expect, or perhaps
that pungi is not as robust as it could be.  I wait a couple hours after I
receive the "rawhide report: <date> changes" that is sent to
fedora-devel-list@redhat.com, then start pungi.  I expect everything to be
propagated by then.  At least, there should be no inconsistencies between
mirrors in "control" files (repodata/*).

What about comparing repodata/* from two mirrors when --mirrorlist is in effect
(instead of --baseurl)?  Or, separating repodata/* into its own category?  Then
I would point repodata/* to the "master mirror" (download.fedora.redhat.com),
and I could tolerate slow or broken mirrors for .rpm and .srpm, because I would
at least find out about them (the checksums would not match.)
Comment 8 Jesse Keating 2007-11-15 14:41:06 EST
mirrormanager is supposed to only return updated mirrors, but it takes
significant time/effort to validate each and every Fedora mirror.  I'm sure that
team is open for suggestions.

I'm closing this bug for now.

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