We have to choose one package for each specific task (be it a server or desktop one) according to the following guidelines.

http://www.rule-project.org/package.html http://www.rule-project.org/package_list.html

NB, to me, this minimum installation is too small to be productive.

It is highly recommended that you build the new installer disks on a system built from the same one you are trying to build. (eg, build a rh72 distribution on a rh72 box using anaconda-7.2). So start off by doing this on a "standard" redhat 7.2 or 7.3 installation. Apply all the current updates to it, including the latest kernel rpm.

Make sure the anaconda and anaconda-runtime packages are installed & updated.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated.

This is the trickiest part of the whole process. This is where you do your own customisations.

To get started with a new fresh installation image, copy the entire contents of all of the original redhat 7.x installation cdroms into a directory called "i386/"

I then have a directory structure on the same physical filesystem and level as the i386/ tree, organised so that it resembles the structure of the redhat updates on the ftp mirror sites:

|
|-- updates
|   |-- i386
|   |-- i486
|   |-- i586
|   |-- i686
|   |-- SRPMS
|   |-- noarch
|   |-- images
|   `-- athlon

# find /redhat/i386 -name TRANS.TBL -o -name rr_moved -o -name boot.cat -exec rm -rf {} \;

cd /redhat/i386/RedHat/RPMS
rpm -K --nogpg *.rpm | grep "NOT OK"

At this point, do the following to make it much more convenient for using the anaconda tools from the command line:

# export PYTHONPATH=/usr/lib/anaconda
# export PATH="$PATH:/usr/lib/anaconda-runtime"

Do this to refresh the i386/RedHat/base/{hdlist,hdlist2} files so that they reflect the changed contents of the i386/RedHat/RPMS/ directory:

# genhdlist /redhat/i386

At this point, it should now be (theoretically) possible to use /redhat/i386/ as an nfs export for network installs using images/netboot.img as the boot image on clients (either via PXE/bootp, or a boot floppy).

This is a good way to test highly customised installations, as you don't need to waste time and money potentially burning a stack of useless cdrom coffee coasters.

The hdlist and hdlist2 files created by genhdlist in RedHat/base don't need to contain accurate information about package ordering if all the rpm packages are available in one place for the installer.

If the contents of i386/RedHat/RPMS/ changes, then genhdlist needs to be run for sure.

Unless you want or need to rebuild the installer itself, this is all that is needed for a network installation image.

This step is not necessary if a package order file exists. A package order file is necessary for subsquent use by splitdistro and genhdlist. It is used to ensure that the ordering and sorting of the rpm files in the i386/RedHat/RPMS/ directories over each of the installation images is consistent and "sane"… if it isn't done properly, then you will find that the installer will repeatedly ask you to swap between the installation disks throughout the installation process.

To create the iso images, mkisofs seems to be what is generally available, it comes standard with redhat, RedHat themselves use it, and it works very well.

I create the iso image in a manner similar to this (example for redhat 7.3):

# cd /redhat/
# myname='Tony Nugent <tony@linuxworks.com.au>'
# bootimg="images/boot.img"
# bootimg="dosutils/autoboot/cdboot.img"
# bootcat="RedHat/base/boot.cat"
# distname="valhalla"
# distvers="7.3"
# mkisopts="-r -N -L -d -D -J"
# today="$(date '+%d %b %Y')"
# mkisofs $mkisopts             \
  -V "RedHat $distver ($distname) UPDATED Disk 1"       \
  -A "RedHat $distver ($distname) update created on $today"     \
  -P "$myname"                  \
  -p "$myname"                  \
  -b "$bootimg"                 \
  -c "$bootcat"                 \
  -x lost+found                 \
  -o "$distname"-1.iso          \
  i386-disc1

# for i in 2 3 ; do
#   mkisofs $mkisopts           \
    -V "RedHat $distver ($distname) UPDATED Disk $i"    \
    -A "RedHat $distver ($distname) update created on $today"   \
    -P "$myname"                \
    -p "$myname"                \
    -x lost+found               \
    -o "$distname"-${i}.iso     \
    i386-disc${i}
  done

If you use a hex-editor to check near the beginning of an iso9660 filesystem image or cdrom created with mkisofs, then you'll find the command-line arguments that were used to create it. For the official valhalla-i386-disc1.iso release, at around offset hex 0xa000 there is this string which reveals exactly how RedHat originally created it in their production environment…

MKI Fri Apr 19 14:54:03 2002 mkisofs 1.14 -A Red Hat Linux/i386 7.3 -V Red Hat Linux/i386 7.3 -J -R -v -T -x ./lost+found -o /mnt/scratch/Valhalla-re0419.5/Valhalla-re0419.5-i386-disc1.iso -b dosutils/autoboot/cdboot.img -c boot.cat .

I like putting the boot.cat file out of the way into RedHat/base/boot.cat so that it is not cluttering the root directory of the cdrom. (The file itself it servers no practical purpose other than being technically necessary for, and an indication of, a bootable El Torito cdrom).

tomsrtbt, "Tom's Root Boot Disk", a self-contained floppy-based linux mini-bootdisk that is useful for running a basic linux system on just about any computer (for rescue, recovery, hardware examination or all sorts of other purposes). There is an El Torito image available for it that works well as a 2.88Mb El Torito boot image on a cdrom.

However, be warned that tomsrtbt has some limitations working with modern distributions such as redhat 7.x… it is based on an old (modified) 2.0.39 kernel, it has bugs that no longer allow it to "chroot" into a kernel-2.4.x-based distribution, and it does not know about ext3, lvm and other more recent filesystem types.

Despite these limitations, it is a very worthwhile tool to have around. I have been using tomsrtbt to make my cdrom data disks El Torito bootable for some time now, and it has proved to be a very useful tool to have so readily available. More recently, a new version stream of tomsrtbt has begun development, using a 2.2.x kernel. See Tom's web site for the latest stable version and for download mirror sites.