so here's what i've discovered about buildinstall thus far --
feel free to jump in and add any comments. also, there's a few
more advanced questions at the end, if anyone's feeling clever.
the purpose of buildinstall is to take a single directory,
RedHat/RPMS, and build installation files and directories around
it, including the images/ and dosutils/ directories, and the
RedHat/base directory which will include the installer images.
in short,
what you start with:
RedHat/
RPMS/
(all your RPMs)
what you finish with:
dosutils/*
images/*
RedHat/
RPMS/
(all your RPMs)
base/
hdstg1.img
netstg1.img
stage2.img
you can then use this as a starting point in building your own
install CDs by adding a "comps" file, running "genhdlist" and so on.
all of the essential scripts are part of the anaconda-runtime RPM,
so make sure that's installed -- the scripts themselves live in
/usr/lib/anaconda-runtime, so (as root) add that to your search path
for convenience, then (keeping it simple):
# cd (your build directory)
# ls
RedHat
# buildinstall .
go grab a coffee, and by the time you get back, you should have the
directory structure above. notice that i kept it simple and didn't
add any options to the buildinstall invocation. that will come later
after i figure it out.
curious issues
------- ------
1) the buildinstall script refers to "COMPNAME=dist-7.0" and a default
VERSION of 7.1. should this be updated to reflect 7.2? if not, what
do they refer to?
2) sadly, it appears that you have to run buildinstall as root, even if
you wanted to do all this under a non-root user account. bummer.
3) buildinstall eventually calls "mk-images", which in turn calls
"mk-images.{ARCH}" for your architecture to build the files in the
images/ directory. does that same script also build the installer
images under base/ ??
4) note that you don't have to say anything about the modules you want
to include, either in boot.img or the installer images. i'm assuming
that this is all done automatically, since running buildinstall
generates a slew of messages like
Module dmx319ld not found in kernel rpm
Module fcal not found in kernel rpm
Module pluto not found in kernel rpm
Module qlogicpti not found in kernel rpm
i'm assuming that these are perfectly normal, right? and no cause
for alarm.
so do you have any control over which modules are included? if you
run buildinstall normally, it appears not.
5) (tricky) this appears to be a bug, or at least an annoying feature,
of buildinstall. consider the code excerpt near the top:
--------------------------------------------------------
UPD_INSTROOT=./upd-instroot
MK_IMAGES=./mk-images
BUILDARCH=`rpm -qp --qf "%{ARCH}" $p/RedHat/RPMS/anaconda-runtime-[0-9]*`
if [ ! -f $UPD_INSTROOT ]; then
cd $BUILDINSTDIR <-------- THIS cd statement, if it's run ...
rpm2cpio $p/RedHat/RPMS/anaconda-runtime-[0-9]* | cpio --quiet -iumd ./usr/lib/anaconda-runtime/upd-instroot usr/lib/anaconda-runtime/upd-instroot
mv usr/lib/anaconda-runtime/upd-instroot .
rm -rf usr
else
cp -a $UPD_INSTROOT $BUILDINSTDIR/upd-instroot
fi
UPD_INSTROOT=$BUILDINSTDIR/upd-instroot
if [ ! -f $MK_IMAGES ]; then <------- ... messes up this test
cd $BUILDINSTDIR
rpm2cpio $p/RedHat/RPMS/anaconda-runtime-[0-9]* | cpio --quiet -iumd ./usr/lib/anaconda-runtime/mk-images* usr/lib/anaconda-runtime/mk-images*
mv usr/lib/anaconda-runtime/mk-images* .
rm -rf usr
else
cp $MK_IMAGES* $BUILDINSTDIR/
fi
MK_IMAGES=$BUILDINSTDIR/mk-images
-------------------------------------------------
what the above is doing is giving you the freedom to copy the
upd-instroot script into the build directory. if you do, it will be
used for the subsequent build. why do you care? you might want
to customize it, or (as i did) put debugging statements into it to
see what was going on. if that script isn't there, buildinstall
just extracts it from the anaconda-runtime RPM.
the same thing is done for the mk-images script, in case you want
to make some changes to that one. *however*, if for one reason or
another, you make a copy of the mk-images* scripts but *not* the
upd-instroot script, buildinstall will not use your personal copy
of mk-images, since it will already have "cd"ed into the BUILDINSTDIR
directory to get its own copy of upd-instroot. in short, the first "cd"
to get a copy of upd-instroot will mess up the subsequent test to see
if you have your own copy of mk-images.
should i be annoyed by this? or should i have expected it?
comments?
rday
