Red Hat Bugzilla – Bug 349701
mulitlib conflicts in composing install media
Last modified: 2013-01-09 20:42:43 EST
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).
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
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?
I will attach the actual .ks file. It shows:
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
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
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
What's the syntax for a specific source repo? Using:
then I get:
Pungi.Gather:INFO: Finished downloading packages.
Pungi.Gather:INFO: Running /usr/bin/xsltproc --novalid -o
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.
Your second url should be:
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
email@example.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.)
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.