[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: CD1 and CD2 swaping like crazy...

On Wed Feb 13 2002 at 16:51, Daniel Shane wrote:

> I have a small problem here, I moved some of the RPMS's in the cd2 into cd1
> and ran the following script to update everything:
> genhdlist --withnumbers ~/cd1 ~/cd2
> pkgorder ~/cd1 i386 > pkgorder
> genhdlist --withnumbers --fileorder pkgorder ~/cd1 ~/cd2
> Now I'm pretty sure that the RPMS that I moved do not have any dependencies
> on the 2nd cd (things like rsh-server for example).
> Now... this script doesnt seem to work since when I install "Everything" it
> starts asking for the 1rst cd while it's installing packages on the 2nd
> cd....
> Should I specify both cd's with pkgorder (pkgorder ~/cd1 ~/cd2 i386 >
> pkgorder) or should the script work as is?
> (As a side note, is the first genhdlist really necessary? Got the script
> from a web page on the net, and I'm not too sure about why there are two
> genhdlists).
> Thanks for your help!
> Daniel Shane

Exactly the same issue hit me with redhat 7.0, and I only recently
managed to figure out how to do it "right" so that this sort of
thing does nto happen.

Please find attached something that I've written about how to create
updated redhat installation cdroms.  It should help to solve your

What I've written here is highly "beta", but it works for me.  I
have yet to "officially release", so any feedback on it would be
appreciated before I do that.

  Tony Nugent <Tony linuxworks com au>
  LinuxWorks - Gold Coast Qld Australia

# >> RedHat 7.2 Customised Installation Disk mini-HOWTO
# >> Tony Nugent <tony(at)linuxworks.com.au>
# >> 27/28th January 2002 Version 0.2 (pre-release)
# >> Thanks to: Scott Sharkey <ssharkey(at)linux-no-limits.com>
# >> Comments and additions gratefully accepted.
# >> I wrote this.  It might all be lies, you take the risk.
# >> It works for me, if you are lucky it might work for you too.
# >> If you reproduce any of this document, kindly give me due credit.

This document describes the basic methodology for creating
customised redhat 7.2 installation cdroms.  The basic principles
described here are likely to apply to previous 7.x redhat
distributions (untested).

Details for creating customised install disks for previous versions
of redhat (6.2 and earlier) can be found here:


While many of the basic principles this document describes are still
very valid, it does not work for rehat 7.x.  The new split-disk
distribution format has changed everything.  Fortunately redhat
provides the anaconda tools that are needed, but at the same time
there is a terse lack of documentation included that describes how
to use it.  (Perhaps it is documented on the rh7.2 documentation -
if it exists.  I have not seen it on any of the redhat sites, nor
have I seen the boxed version).

My basic aim was to create customised rh72 installation cdroms that
already contained all the update packates already added to them.
This avoids having to go through the tedious and often perilous
hassle of appling them all after the initial installation.

  As of Jan 2002, the total size of just the i386 binary update
  packages for rh72 had bloated to 550Mb (with another 370Mb for the
  src.rpm packages).  Repeatedly applying all that lot to every new
  installation is a real headache... kernels (generally) need to be
  install and not upgraded or freshened, some packages are new and
  need installing before some of the updates, choose between
  freshening the glibc-i386 or glibc-i686 package and so on.  Yuk!
  Much better to have as many of the updates in there right at the
  initial installation.

Nine easy (??) steps:
	1	Prepare the build system
	2	Prepare the build source tree
	3	Generate a new hdlist
	4	Generate a package order file
	5	Rebuild the anaconda installer images
	6	Split the installation image into several CDROM images
	7	Re-generate new hdlist files (again)
	8	Create the iso9660 filesystem images
	9	Burn (and test) the cdroms

Step 1	Prepare the build system
------	------------------------

Start off by doing this on a "standard" redhat 7.2 installation.
Apply all the current updates to it, including the latest kernel
rpms.  Do it, you have been warned.

Install the (updated) kernel-BOOT package.

Install the anaconda and anaconda-runtime packages.

Get the latest redhat update-disk image, loop-mount it, and replace
the corresponding files in your /usr/lib/anaconda/* tree with the
versions contained in the update.  (Some of them go into one of the

  It is important to do this... it will mean that you will not need
  to use the update boot disk from the redhat 7.2 updates for the

Step 2	Prepare the build source tree
------	------------------------------

This is the trickiest part of the whole process.  Designing
customised redhat-based installation images is beyond the scope of
this discussion, details can be found elsewhere.  What is described
here is how to produce working installation disks from your
customised install image.

To get started with a new fresh installation image, copy the entire
contents of both of the original redhat 7.2 installation cdroms into
a directory called "i386" on a partition that has plenty of space
available for what you need to do.  For example purposes, I'll use
/redhat72/i386/  (I'm using intel-based linux).

  See the README in the base directory of the distribution cdroms.
  All the RedHat/RPMS/*rpm files from both disks should now be
  together in the same directory, exactly how it should be as for an
  NFS export for network installs.

Carefully and attentively replace, add or remove packages as you see
fit to RedHat/RPMS/*.  Make sure package dependencies are satisfied,
and don't forget to modify the RedHat/base/comps file if you need to
add or remove mention of any packages you have changed.

  BEWARE:  (for redhat 7.2)

	1. Mention of the Omni and Omni-foomatic packages needs to be
           made to comps (required after the update for ghostscript).

  	2. The Jan 2002 KDE update packages do not fully replace the
	   original distribution packages, the packages that are
	   installed after the update have different names.  Look
	   for mention of these files in the comps file and make
	   alterations accordingly.  (eg, the kde-i18n-Chinese
	   package is now missing).

The RedHat/, images/ and dosutils/ are standard (and expected) in
the i386/ build source directory.  If you add or remove any
additional files or directories to your installation root, they
are added to the first install disk image exactly as is.

Put all the *.src.rpm packages into a SRPMS/ directory alongside the
i386/ directory (eg, into /redhat72/SRPMS/).

Before moving on from here, make sure that everything in this
"buildroot" (/redhat72/) is in the right place.

Step 3	Generate a new hdlist
------	---------------------

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"

  If you get errors running any of the anaconda tools (genhdlist,
  pkgorder, buildinstall, splitdistro), then the first things to
  investigate are inconsistency problems in the comps file and
  missing or corrupt packages and/or dependencies in the RPMS/

Generage new i386/RedHat/base/hdlist{,2} files:

	# genhdlist /redhat72/i386

Note, no options to genhdlist (at this time).

Step 4	Generate a package order file
------	-----------------------------

	# pkgorder /redhat72/i386 i386 | tee /redhat72/pkgorder.txt

Check for error messages in the output (which is why I use tee).

Step 5	Rebuild the anaconda installer images
------	-------------------------------------

	# buildinstall --pkgorder /redhat72/pkgorder.txt /redhat72/i386

This will rebuild most (all?) of the install boot images in
i386/images/ and i386/dosutils/autoboot/, as well as the anaconda
installer runtime images in i386/RedHat/base/*.img (hdstg1.img,
netstg1.img, stage2.img).

If you don't have the kernel-BOOT package installed, then
bootinstall will give lots of complaints about things like missing

  It is likely that at just before this point it is possible to
  reconfigure the buildinstall to include things like your own
  customised install boot drivers if you need to do that.  This is
  useful for, eg, kickstart installing a big bunch of cloned
  machines that all happen to have some weird hardware that need
  special drivers for accessing the installation media.

Building new installer images should also negate the need to use the
libparted.so library found in the redhat 7.2 update boot disk (both

  At this point, it should now be (theoretically) possible to use
  /redhat/i386/ as an nfs export for network doing installs using
  netboot.img on clients.  (Untested, but it should work).  This is
  a good way to test highly customised installations, as you don't
  need to waste time burning potentially useless cdroms.

Step 6	Split the installation image into several CDROM images
------	------------------------------------------------------

	# splitdistro --fileorder /redhat72/pkgorder.txt /redhat72 i386

This will create a series of directories alongside the i386/ and
SRPMS/ directories, called i386-disc1/ i386-disc2/ i386-disc3/ and

These directories contain a "split" of the original (larger) image
in i386/ spread over 4 directories (two installers, and two for all
the src.rpm files), suitable for creating iso images for burning to

  All the files in these directories are hard-linked to the original
  files of the same name in the i386/ directory tree.
  This is very cool, the hard links are not copies of the original
  files, the hard-linked files just point to the same disk inodes.
  The files themselves are not copied, which means that very little
  time and disk space is actually used to obtain a "copy".

By the way, you can safely do "rm -rf /redhat72/i386-disc*" if you
want to, it will simply delete the directory trees with all the
hard-linked filenames.  Simply run splitdistro again to (quickly)
recreate it all.

  Note that /usr/lib/anaconda/splitdistro can be hacked to set the
  size limit of the final images.  This is handy... after the
  updates and other additions I tend to add, the final result is
  close to two full 700Mb install images - no problem with blank
  700Mb disks but too much for 650Mb (the default).  650Mb just
  doesn't cut it any longer :-)
  (The day when distributions are released on DVD as standard is
  coming quickly...)

Step 7	Re-generate new hdlist files
------	----------------------------

Delete the i386-disc1/RedHat/base/hdlist* files, they are
hard-linked copies of those in i386/RedHat/base/ and they are very
likely not to work on cdrom.   Then generate new ones...

	# rm -f /redhat72/i386-disc1/RedHat/base/hdlist*
	# genhdlist --withnumbers --fileorder /redhat72/pkgorder.txt \
	/redhat72/i386-disc1 /redhat72/i386-disc2

Note all the options to genhdlist, they are important.  If you don't
do it like that, then it is likely that you'll end up with an
installation that repeatedly asks for disc1 and disc2.  The package
order file prevents this so that only one disc change is ever

And now congradulations, this completes the preparation of the cdrom
source tree images.

Step 8	Create the iso9660 filesystem images
------	------------------------------------

Use whatever tools you like to do this, with your own options.  I do
it something like this:

	# cd /redhat72/
	# mkisofs -r -N -L -d -D -J	\
	-V "RedHat 7.2 (enigma) UPDATED"	\
	-A "RedHat 7.2 (enigma) update created on 27 Jan 2002"	\
	-P "Tony Nugent <tony linuxworks com au>"	\
	-p "Tony Nugent <tony linuxworks com au>"	\
	-b images/boot.img	\
	-C RedHat/base/boot.cat	\
	-x lost+found	\
	-o enigma-1.iso	\

Some people would question the use of -r over -R, -d -D and -N.
But it works for me.

Don't forget to make the first iso image bootable with the
images/boot.img file (or perhaps the pcmcia.img file if you want to
boot the cdrom for installing onto laptops).

  I like putting the boot.cat file out of the way into RedHat/base/.

  Don't make the second and subsequent images bootable -- although
  if there is space, there is no reason why you couldn't manually
  add your own cdrom boot image tree to any of the other image
  trees.  Check freshmeat.net for tomsrtbt (it has an ElTorita boot
  image), mindi, and other similar tools.

Step 9	Burn the cdrom images
------	---------------------

Assuming that you have a scsi or ide-scsi (atapi) cdrom writer
installed as device 3...

	# cdrecord -v dev=0,3,0 speed=12 fs=20M -eject -data enigma-1.iso

Testing with cd-re-writables at this point is advised, you'll need
to do a test installation with your result to confirm that it all
went well and works as advertised.  But if you got this far, the
chances are that it will work just fine.

It works for me :-)

Step 10	Enjoy!
-------	------

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]