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): pungi-1.1.6-1.fc8 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 all). 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" ?
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: ----- repo --name=rawhide --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch repo --name=rawhide-source --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide-source&arch=$basearch ----- 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.
Created attachment 235741 [details] /usr/share/pungi/f8-fedora.ks 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.
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 ?
What's the syntax for a specific source repo? Using: ----- repo --name=rawhide --baseurl=http://download.fedora.redhat.com/pub/fedora/linux/development/x86_64/os repo --name=rawhide-source --baseurl=http://download.fedora.redhat.com/pub/fedora/linux/development/x86_64/os ----- 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 /data/Fedora8/work/x86_64/Fedora-8-comps.xml Error: Cannot find a source rpm for pcmciautils-014-11.fc8 ----- even though firefox can see http://download.fedora.redhat.com/pub/fedora/linux/development/source/SRPMS/pcmciautils-014-11.fc8.src.rpm 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: repo --name=rawhide-source --baseurl=http://download.fedora.redhat.com/pub/fedora/linux/development/source/SRPMS
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, 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.