This document describe how to rebuild RedHat 7 distribution CDs,
after
changing RPMS and instalation program (anaconda).
______________________________________________________________________
Introduction
This is a mini howto, it's provided as is, I don't know if I
will
maintain it or not. It's intended to help people to rebuild RH7 CDs,
something that is not as trivial as it may seem. This is based upon
my own experience on creating a
RH7 instalation with ReiserFS support.
Requirements
- Original RedHat7 CDs, iso images or their contents
- At least 1.5Gb of free space (more for iso images creation)
- Installed RedHat7 with compilers, utilities, etc
1) Rebuilding RPMS
Building RPM is outside the scope of the present document, but
there
are some worth mentioning notes. It is important to recompile RH7 rpms
FROM an installed RH7 linux. Doing it from RH 6.2, for example, can
be
very painfull because of different library, compiler, headers and rpm
versions.
If you don't have experience with rpm, get a .src.rpm file to
begin.
This will be installed in directory /usr/src/redhat where you
can play with it.
If you want to make changes to the installer and/or generation
of
media sets (e.g. to change a driver from boot disk to second stage
because lack of disk space due to a bigger kernel) you should install
the anaconda source. Anaconda is a fairly complex program which handles
partitioning, hardware detection, X, newt, python and more. Use the
original RH7 kernel headers to rebuild anaconda as it may depend heavly
on them.
2) Exchange or add new RPMS
Create two directories, eg., ~/cd1 and ~/cd2 where the contents
of
original RedHat CDs should be copied. This is your working area.
I prefer to keep RPM files separated on two (or more) cds since
the
beggining. Unfortunately, this has some minor implications that I
will mention below. If you want you can copy all files to the
same
place, edit them, and just before step 4 break them in 2 pieces
(< 650Mb each).
Now you may change whatever RPMS you want in both cds. Suppose
you
want to update kde1 to kde2. You can download the rpms from kde.org
and them carefully substitute the original files. You may copy new
files to the same CD they were originally, taking care to remove the
old ones.
NEVER, EVER, COPY THE SAME RPM TO BOTH CDs! The genhdlist utility
(see below) supplied on RH7 does not handle duplicated files correctly
and the result will be an instalation that looks for a crazy cd number
like -2172326.
I don't know what is the criterion RedHat uses to place some
rpm on
the first or second disk. I thought it was something like "more
important stuff first", as can be noted from the fact that when
installing RH7 with the minimum packages you are not asked for
the second disk. A more carefull look in their disks reveals that this
must not be true: there are catalan and czech dictonaries on the first
cd! (nothing personal, they just aren't the biggest market share RedHat
should be looking forward...)
So I follow the "more important suff first" paradigm, moving
packages to the second disk as I run out of space on the first.
3) Editing file "RedHat/base/comps"
This file tells anaconda what packages should be installed if
the user
selects a particular group. If you ever installed a system using
anaconda you should know what these groups are (printer support, X
window, gnome, kde and so on).
Edit the file cd1/RedHat/base/comps to include any packages you
might have added in a particular group. You may not need this step
depending on what have you changed.
Some examples:
3.1) I added the reiserutils package that contains
programs for
creating ReiserFS partitions. Of course this must be always installed
as
it is a basic requirement to be able to create a new partition. This
is
as important as e2fsprogs-xxx.rpm and it's mkfs program.
1 Base {
...
e2fsprogs
...
reiser-utils <- new package inside group
"Base"
...
}
3.2) The new kde2 desktop requires a library called
libmng. You
don't HAVE to add libmng to comps, but doing so you should avoid a
depedence error during instalation.
4) Generating file "RedHat/base/hdlist" (genhdlist)
The hdlist file is very familiar for everyone who had generated
RedHat 5.x, 6.x before. hdlist contains information about all packages
available. This information is used during the instalation to show
what
each package does and to resolve depedence problems after user selects
them.
The program used to generate hdlist is called "genhdlist".
It's part
of anaconda-runtime package and is installed at /usr/lib/anaconda-runtime.
"genhdlist" now includes a new parameter called "--withnumbers"
to record the media number for each rpm in hdlist.
Step-by-step procedure:
# rpm -i anaconda-runtime-xxxxx-i386.rpm
# cd /usr/lib/anaconda-runtime
# ./genhdlist --withnumbers --hdlist ~/cd1/RedHat/base/hdlist
~/cd1 ~/cd2
Don't change the order of cd1 and cd2, you might guess
why. Don't
forget "--withnumbers" and that's all.
Also note that there's no particular time to do this. I
put it as
step 4 just for convenience but it may be you last step. Step 5 does
NOT
depend on this one.
If you have not changed neither kernel, anaconda or any
important
package to the instalation program, congratulations! You may record
you
new RH7 cds now (step 6).
5) Rebuilding installation stages
The installation program cannot be loaded in just one turn,
it must
be broken into pieces, usually called "stages". The first stage is
very
small, as it may be loaded from a floppy disk, tftp server and so on.
Usually this stage contains only a stripped down version of the linux
kernel
and some drivers (like scsi) that are needed to load the following
stages.
There are a lot of images that must be generated for a
new RedHat
linux installation. The most obvious one is the boot disk itself (to
install from cd or floppy), but we also must support installations
from hd, nfs, etc.
RedHat provide us great scripts to do all this in a single
shoot.
The job of these scripts is to extract the contents of some RPMs and
use
their files to create the stage images.
Again we must have anaconda-runtime installed:
# rpm -i anaconda-runtime-xxxxx-i386.rpm
Them go to directory /usr/lib/anaconda-runtime where we
have some
usefull scripts to look:
5.1) mk-images.i386 - Contains i386 specific settings for
creating
boot disks (normal, network and pcmcia) and supplemental disk drivers.
Here you may change what modules should be included in each boot image.
For example, at the network boot disk we have:
...
NETWORKMODULES="$COMMONMODULES 3c509
3c59x 3c90x 8390 ac3200
at1700 de4x5 de600
de620 depca dgrs eepro100 eepro hp-plus hp
hp100 ne ne2k-pci
ni52 old_tulip pcnet32 rtl8139 tlan tulip
via-rhine nfs vfat"
...
5.2) upd-instroot - This one extracts rpms from media sets
to be used
in installation. To avoid wasting space, it also has a list of files
that
must be preserved after rpm extraction (every file not listed here
will
not be copied to any stage). In other words, if you want to include
a new
file on anaconda images you must must set the rpm that contains it
AND
also the file name. Again, let's use reiserfs example:
...
PACKAGES="glibc setup openssl python
newt libtermcap zlib
e2fsprogs util-linux raidtools ... reiser-utils <-
HERE!
...
sbin/ldconfig
sbin/mkdosfs
sbin/mkreiserfs <- HERE!
sbin/mke2fs
sbin/mkfs.ext2
...
5.3) buildinstall - The main one. This is very easy to use:
# cd /usr/lib/anaconda-runtime
# ./buildinstall ~/cd1/
All other scripts will called automatically
where needed. Note
that if you are working with cd1 and cd2 files (like me) you must be
sure
every required rpm is on the first cd. In particular you must MOVE
the
file syslinux-xxx-i386.rpm from the second to the first cd. RedHat
probably
left this at the second cd because they separate the files later. If
you
don't have separated the cds yet, just ignore this. Do not COPY this
file,
instead of MOVING, or you will get the error mentioned in step 4 of
this
document.
The script will create a lot of files
at ~/cd1/images and
~/cd1/RedHat/instimage. The last one is the nfs installation tree and
is
originally provided by RedHat on the second cd, so you may move it
if
you want.
6) Creating iso images
The only catch is to be sure the first CD will be bootable.
In order
to do that, try comands like these:
# mkisofs -V <label> -b images/boot.img -c boot.cat
-J -r -T -o cd1.iso ~/cd1
# mkisofs -V <label> -J -r -T -o cd2.iso ~/cd2
I like to use -J (joliet) so it can also be read on Windowz
systems.
If you plan to distribute these iso images over the net,
consider
generating a md5 "checksum", so others could be sure to have the file
intact.
# md5sum *.iso > MD5SUM
<end>