Description of problem: Somehow the DVD.iso that is composed by pungi contains pieces of anaconda that are not derived from the anaconda*.rpm that is in the repo.
Version-Release number of selected component (if applicable):
pungi-2.0.4-1.fc10.noarch
How reproducible: always
Steps to Reproduce:
1. Run a compose with anaconda-11.4.1.34-1.i386 in the repo, but anaconda-11.4.1.33-1.i386.rpm installed (n.b. '33' vs '34'). The command I used was:
pungi -c /usr/share/pungi/rawhide-fedora.ks --force --destdir=/data/Fedora10 --name Fedora --ver 10 --nosource
2.
3.
Actual results: After burning and booting the DVD.iso, then the installer announces itself as 11.4.1.33 (the version that is installed on the machine that ran the pungi compose.)
Expected results: The installer announces itself as 11.4.1.34 (the version that is in the repo.)
Additional info: /usr/lib/anaconda-runtime/buildinstall near line 168 always downloads anaconda from the repo, and then unpacks some new pieces for use:
-----
pushd $BUILDINSTDIR
BUILDARCH=`repoquery -c $yumconf --qf "%{ARCH}\n" anaconda`
yumdownloader -c $yumconf anaconda || exit 1
rpm2cpio anaconda*rpm | cpio --quiet -iumd './usr*'
rm -f anaconda*rpm
popd
for f in $UPD_INSTROOT $MK_IMAGES $MK_STAMP $MK_TREEINFO $BUILDINSTALL; do
if [ -n "$UPDATES" -a -f $UPDATES/usr/lib/anaconda-runtime/$f ]; then
cp -a $UPDATES/usr/lib/anaconda-runtime/$f* $BUILDINSTDIR/
elif [ ! -f $f ]; then
cp -a $BUILDINSTDIR/usr/lib/anaconda-runtime/$f* $BUILDINSTDIR/
else
cp -a $f* $BUILDINSTDIR/
fi
done
-----
It is unclear whether this covers *all* the pieces of anaconda that go into the composed DVD.iso.
The pungi console announces:
Pungi:INFO: Running /usr/lib/anaconda-runtime/buildinstall --product Fedora ...
which obviously uses the installed buildinstall for some things. Perhaps using it for "control" of the compose process itself is OK, but using it for "data" that appears in DVD.iso is questionable.
If the installed buildinstall does leak some of its pieces into DVD.iso, then pungi should warn if buildinstall does not correspond to the anaconda in the repo.
The fact that buildinstall always downloads anaconda means that it is dangerous to use the --mirrorlist= construct in the pungi *.ks file. There is no record of which mirror supplied which actual version of anaconda, and it is unclear what kind of consistency checking gets performed [in particular, the version seen by pungi vs the version seen by buildinstall.] Mirror skew exists today and is unlikely to be eradicated soon. Because downloading is non-instantaneous, then even the same mirror can have skew between the beginning and the end of a pungi compose.

This is on purpose. pungi tries to use as much of the locally installed anaconda as possible. In fact, in future rewrites of buildinstall scripts, they won't download a new anaconda and instead pull the bits from the installed anaconda.

Note

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