LuigiBitonti

uknadors (at) yahoo (dot) com

Author of the current version and maintainer. MortenKjeldgaard

Author of the original version. Petervon der Ahent

Author of the original version. v2.012002-12-04lb Second release of the new version of the howto. All the scripts were reviewed and cleaned. The updateDist.sh script now checks that all the updates were downloaded before checking the signatures. v2.002002-10-28lbFirst release of the new version (2.00) of the HOWTO2002Luigi Bitonti2000Morten Kjeldgaard, and Peter von der Ahent This document describes how to make your own CDs from different releases of the Red Hat Linux distribution (up to and including release 8.0), equivalent to the ones commercially available from Red Hat. The structure of the distribution is described, as well as the procedure needed to include updated RPMS into the distribution. Some hints and examples on how to customize the default installation are also presented. Scripts to automate as much as possible the (re)generation of the CD images are included. Prerequisites are a good network connection, and a CD-writer (a working knowledge of shell scripting could be really useful, though). There may be several reasons for making your own CDs. Perhaps you're a cheapskate and want to save the cost of the Red Hat distribution. Or, perhaps you want to include in your CDs the latest distribution with all the current updates. This is highly relevant, because after each major release of the Red Hat distribution, there have been loads of updates, several of which are security related. Just take a look at the errata page. Or maybe you want to customize the default installation adding a few packages not present in the default tree and unselecting the installation of some packages which are otherwise included in the default setup. This is what you will be taught in the next sections (hopefully). I will use the i386 architecture and releases 7.3 and 8.0 of the distribution in the examples. The notes related to the previous releases (ent=6.1) were contained in a previous version of this document and were compiled by the original authors. The notes related to release 6.2 are based on tests I've not completed (and I don't know if I ever will) and some documents you can find linked in the section. The procedure given in the following sections for RedHat 7.3 and 8.0 is likely to work on all platforms supported by Red Hat (Alpha, ppc, etc.), for all the 7.x (and maybe 8.x in a not too far future) releases, but I have only tested it on the i386 platform with Redhat Linux 7.3 and 8.0 (I would be interested in additional information). The operations described have legal implications, meaning you cannot redistribute the CDs as RedHat Linux if you modify them in ways not compliant to Redhat trademark policy. To make them legally redistributable, you should always comply with the guidelines stated on the RedHat website . Always remember to set the variables in the rhcd.conf file and export the RHCDPATH environment variable before running the scripts you will find throughout the rest of this document and related to releases ent=6.2 of RedHat Linux. An example rhcd.conf file, which should be well commented, is provided with the scripts. This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Neither the author nor the distributors, or any other contributor of this document are in any way responsible for physical, financial, moral or any other type of damage incurred by following the suggestions in this text. In the spirit of the Linux community, Red Hat Software has made available their Linux distributions for several platforms on their FTP site. These are all available from the top distribution directory (pub/redhat/linux/). Let's have a look at the distribution tree. The latest distribution is, as of this writing, available only for the i386 platform. The toplevel directory appears a bit shallow, given the presence of a single architecture. (pub/redhat/linux/8.0/en/os/ ). i386/ Otherwise, the toplevel directory, for releases slightly older than 8.0, contains distributions for the different platforms. For example, the corresponding directory for release 7.1 of Redhat Linux, is structured this way: alpha/ i386/ ia64/ ppc/ s390x/ The root of the i386 directory looks like this: -rwxr-xr-x 1 root root 248 Sep 10 21:19 autorun drwxr-xr-x 7 root root 4096 Oct 25 10:43 dosutils -rwxr-xr-x 1 root root 6194 Sep 10 21:19 EULA -rwxr-xr-x 1 root root 18385 Sep 10 21:19 GPL drwxr-xr-x 3 root root 4096 Oct 25 10:43 images drwxr-xr-x 2 root root 4096 Oct 25 10:43 isolinux -rw-r--r-- 1 root root 28320 Oct 24 22:36 pkgorder.txt -rwxr-xr-x 1 root root 5350 Sep 10 21:19 README -rwxr-xr-x 1 root root 13342 Sep 10 21:19 README-Accessibility -rwxr-xr-x 1 root root 5781 Sep 10 21:19 README.de -rwxr-xr-x 1 root root 5956 Sep 10 21:19 README.es -rwxr-xr-x 1 root root 6351 Sep 10 21:19 README.fr -rwxr-xr-x 1 root root 5684 Sep 10 21:19 README.it -rwxr-xr-x 1 root root 6836 Sep 10 21:19 README.ja -rwxr-xr-x 1 root root 6566 Sep 10 21:19 README.ko -rwxr-xr-x 1 root root 4965 Sep 10 21:19 README.zh_CN -rwxr-xr-x 1 root root 5267 Sep 10 21:19 README.zh_TW drwxr-xr-x 4 root root 4096 Oct 25 10:43 RedHat -rwxr-xr-x 1 root root 37493 Sep 10 21:19 RELEASE-NOTES -rwxr-xr-x 1 root root 47340 Sep 10 21:19 RELEASE-NOTES-de.html -rwxr-xr-x 1 root root 44726 Sep 10 21:19 RELEASE-NOTES-es.html -rwxr-xr-x 1 root root 47994 Sep 10 21:19 RELEASE-NOTES-fr.html -rwxr-xr-x 1 root root 42160 Sep 10 21:19 RELEASE-NOTES.html -rwxr-xr-x 1 root root 44680 Sep 10 21:19 RELEASE-NOTES-it.html -rwxr-xr-x 1 root root 56720 Sep 10 21:19 RELEASE-NOTES-ja.html -rwxr-xr-x 1 root root 50814 Sep 10 21:19 RELEASE-NOTES-ko.html -rwxr-xr-x 1 root root 37770 Sep 10 21:19 RELEASE-NOTES-zh_CN.html -rwxr-xr-x 1 root root 39122 Sep 10 21:19 RELEASE-NOTES-zh_TW.html -rwxr-xr-x 1 root root 1910 Sep 10 21:19 RPM-GPG-KEY -rwxr-xr-x 1 root root 338 Sep 10 21:56 TRANS.TBL The SRPMS directory contains the RPMS packages in source form. The images directory contains boot and drivers floppy images that can be copied to a diskette if needed. In the 8.0 release, there are three boot disk images available. The first boot image is called boot.img, and is required when installation is performed directly from a CD-ROM. If installing from a NFS mounted disk or FTP is required, the bootnet.img disk image is needed. Installs through PCMCIA adapters need the pcmcia.img floppy. See section and references therein for details and consult the README file in the directory for a more detailed explanation of the various files. The isolinux directory contains the files needed to boot from the CD (and to rebuild bootable CDs which work the same way). This process was moved from floppy emulation to no emulation. This helps avoiding space constraints and compatibility problems. The dosutils directory contains various programs for some other operating systems which are sometimes useful to support the installation process. An explanatory README file is included also in this case. The listing is completed by a lot of files and the RedHat directory. The latter is the subject of the next sections while the formers have contents which will appear straightforward by simply reading their names (perhaps apart from the EULA, or End User License Agreement). The most important part of the directory tree is rooted in the RedHat directory: drwxr-xr-x 2 root root 53248 Jun 14 03:15 RPMS drwxr-xr-x 2 root root 4096 Jun 14 04:15 base The RPMS directory contains the major part of the Red Hat distribution consisting of a set of RPM (Redhat Package Manager) files. An RPM package typically contains binary executables, along with relevant configuration files and documentation. See the section for more information. The base directory holds different files needed during the installation process, like the comps.xml file, which defines the components (groups of packages) used during the "Choose packages to install" phase. See section for more information on this file, and how to use it. Two other important files in the base directory are hdlist and hdlist2 containing most of the header fields from all the RPMs in the RPMS directory. This means that all the interdependencies among RPM packages can be determined just by reading these files without having to read all the RPM packages which is quite convenient especially during FTP installs. Another use of these files is mapping package names to file names (eg. perl to perl-5.004-6.i386.rpm). This means that if you want to incorporate updates from RedHat (see section ) or add your own packages to the RPMS directory, you need to update hdlist and hdlist2. This is described later in . Besides these files, the images from which the installation environment (i.e. kernel, python interpreter, anaconda, etc.) is loaded are found. The /pub/redhat/linux/updates directory has updates for all releases of RedHat's distribution since version 3.0.3. This is the place to find software packages that have been updated for some reason or other. You should especially be aware of security updates. These are publicised on RedHat's errata page whenever a fix is available. The most important files found in the updates directory are: drwxrwsr-x 3 root root 4096 Jul 13 10:13 5.2 drwxrwsr-x 3 root root 4096 Jul 13 10:13 6.0 drwxrwsr-x 3 root root 4096 Jul 13 10:13 6.1 drwxrwsr-x 4 root root 4096 Jul 13 10:14 6.2 drwxrwsr-x 4 root root 4096 Jul 13 10:14 7.0 drwxrwsr-x 4 root root 4096 Jul 13 10:14 7.1 drwxrwsr-x 4 root root 4096 Jul 13 10:13 7.2 drwxrwsr-x 3 root root 4096 Jul 13 10:14 7.3 drwxrwsr-x 3 root root 4096 Jul 13 10:14 8.0 The structure of each of these directories is similar to that described in the section . So you will find for each version, in the subdirectory en/os/ a series of subdirectories representing the various architectures and a noarch and SRPMS subdirectories, for packages which work on every architecture or are in source form respectively. drwxrwsr-x 2 root root 4096 Sep 23 05:28 SRPMS drwxrwsr-x 2 root root 4096 Aug 28 18:25 athlon drwxrwsr-x 2 root root 8192 Sep 23 05:28 i386 drwxrwsr-x 2 root root 4096 Jul 13 10:14 i486 drwxrwsr-x 2 root root 4096 Aug 28 18:26 i586 drwxrwsr-x 2 root root 4096 Aug 28 18:26 i686 drwxrwsr-x 2 root root 4096 Jul 13 10:14 noarch The two distributions are fairly similar in this respect. The only changes which are of some interest to us (and easy to notice with a simple inspection of the main distribution tree) are represented by a missing isolinux directory and some changes in the RedHat/base directory. The first one is due to the way the installation CDs are made bootable in releases prior to 8.0 (floppy emulation has been superseded by no emulation in release 8.0), while the second is an effect of the migration of the comps file format to XML in Redhat 8.0 (that's why it was renamed comps.xml). The Redhat/base/comps file is, in fact, a simple textual file with a quite inflexible syntax in releases prior to and including Redhat 7.3. For release 6.2 ( pub/redhat/linux/6.2/en/os/), the last of the 6 series, the organization is the following (the previous releases are mostly similar if not really equal, in this respect): alpha/ i386/ sparc/ While the root of the i386 directory looks like this: -rw-r--r-- 1 root root 18385 Sep 7 1999 COPYING -rw-r--r-- 1 root root 3400 Mar 8 2000 README -rw-r--r-- 1 root root 16300 Mar 8 2000 RELEASE-NOTES -rw-r--r-- 1 root root 1908 Sep 25 1999 RPM-GPG-KEY drwxr-xr-x 1 root root 512 Sep 27 15:22 RedHat drwxr-xr-x 1 root root 17408 Sep 27 15:22 SRPMS -rwxr-xr-x 1 root root 538 Sep 26 1999 autorun -rwxr--r-- 1 root root 2048 Mar 9 2000 boot.cat drwxr-xr-x 1 root root 512 Sep 27 15:22 doc drwxr-xr-x 1 root root 512 Sep 27 15:22 dosutils drwxr-xr-x 1 root root 512 Sep 27 15:22 images drwxr-xr-x 1 root root 512 Sep 27 15:22 misc In the following paragraphs I will only list differences from the newest releases, what is not explicitly mentioned is (or is believed to be) unchanged. The doc directory contains an abundance of information. Most importantly, the RedHat installation manual can be found in HTML format in the directory or on the Redhat website ( Redhat 6.2 Installation guide). Next, there are the reference guide and the getting started guide. The documentation for the 7.x/8.x releases is on a separate CD (in a different tree, on the ftp site). The images directory contains boot floppy images that can be copied to a diskette if needed, like for 8.0 and 7.3. See section and references therein for details. The misc directory contains source and executables of a number of programs needed for the installation. The most important part of the directory tree is (again) rooted in the RedHat directory: drwxr-xr-x 2 root root 28672 Oct 26 09:01 RPMS drwxr-xr-x 2 root root 4096 Oct 26 09:01 base -rw-r--r-- 1 root root 0 Jan 19 1999 i386 drwxr-xr-x 6 root root 4096 Oct 26 09:01 instimage The RPMS directory should be already known to you. See the section for more informations. The base directory holds different book-keeping files needed during the installation process, like for releases 7.3 and 8.0. The only noticeable differences being represented by a single hdlist file and a missing stage2.img file whose functionalities should be provided by the files included in the instimage directory. This contains, in fact, a bare-bones live file system with a number of programs and shared libraries needed during the installation procedure. The updates directory is really similar to the one described for release 8.0 with the only difference of having more architecture related directories. The major part of the Red Hat distribution consists of a set of RPM (Redhat Package Manager) files. An RPM package typically contains binary executables, along with relevant configuration files and documentation. The rpm program is a powerful package manager, which can be used to install, query, verify, update, erase and build software packages in the RPM format. Rpm convieniently maintains a database of all the software packages it has installed, so information on the installed software is available at any time. The binary RPM files in the distribution have been built on a system running the distribution itself. This is important, because most of the programs in the packages rely on shared libraries. From RedHat version 5.0, the new version 2 of the GNU standard C library (which is 64-bit clean) has been used. This version of the library is commonly referred to as glibc or in Linux: libc 6. All executables in the distribution have been linked against this library. If you attempt to install binary files from a different distribution, chances are that they will not work, unless you install the libc5 package for backwards compability. There are also incompatibilities between the various version of the Redhat Package Manager itself which will make the installation of some packages fail even on machines they are supposed to (and they would probably) run on. The names of the RPM packages contain the suffix .arch.rpm, where arch is the architecture, usually having the value i386 for Intel platform binaries. The packages you install must match the versions of the shared libraries available on the machine. The rpm program is usually quite good at ensuring that this is indeed the case, however, there are ways around this check, and you should be sure that you know what you are doing if you force installation of packages this way. However, using the RedHat installation boot disk, it is ensured that the correct set of RPM packages are installed on the machine. If you discover a RPM package that was not installed on your system during the installation process, don't despair. At any time, you may (as root) install RPM packages, for example: # rpm --install WindowMaker-0.18-1b.i386.rpm You can even install directly from the Internet, if you know the URL of a RPM package: # rpm --install ftp://rufus.w3.org/redhat-contrib/noarch/mirror-2.9-2.noarch.rpm If you want to update (or install if it's not present on the machine) a RPM package, use the command: # rpm --update WindowMaker-0.18-1b.i386.rpm If you want to update a RPM package only if a previous version is already installed on the machine use the command: # rpm --freshen WindowMaker-0.18-1b.i386.rpm Another version of the RPM packages contains the original sources used to build the binaries. These packages have the suffix .src.rpm and are situated in the SRPMS directory. These packages compose the last two CDs and part of the third one out of the five which compose the 8.0 (or 7.3) release. For 6.2 (and previous, not too old, versions), things change a bit because there is only one installation CD not comprising the SRPMS packages, which you can burn on a different disc, if you want. To obtain more informations on the Redhat package manager, I suggest you to read the man pages and the fairly detailed book maximum rpm. In the next section, I will introduce a C program which will be used in various scripts throughout the rest of the howto. It just returns, given two versions of the same RPM package, which one is newer. This program is based on the code used in the Redhat Package Manager (release 4.1) and is used when the --freshen option is given. The C code included in the three files Makefile, rvc.h, rvc.c was extracted from the Redhat Package Manager and (slightly) modified to fit our needs. They form a simple C program which given two versions A and B of a package returns 1, 0 or -1 if A is respectively newer, equal or older than B and other values in case of error (you can read the code comments for more detailed informations). To compile the program (you need the make program and the gcc C compiler), put the files in the same directory and issue the command: $ make This program is needed by almost every script used in the following sections and is found setting the RVC variable in the file rhcd.conf. You can find a copy of the source and a precompiled version in the archive rhcd-sripts.tar.gz in the rpmvc directory. You need a copy of the distribution on a writable disk which is accessible from the computer having the CD writer (duh!). If you want to incorporate the latest updates, this directory should (also) be accessible from a Linux machine, either from a local disk, an NFS mounted disk on a different computer, or a JAZ disk. You could copy the distribution from the RedHat CDs (recommended), or you could get it via FTP. If you choose to use FTP, there are two ways of doing it. You can use the wget based shell script presented in the following section or the mirror package as suggested in versions up to and including 1.34 of the howto (reported in section ). This is not the simplest, even if, probably, the most accurate way. I like it because it works comparing the RPM versions of the files and not the dates/times or names (like the standard mirroring packages) and it checks the signatures of the updates each time it downloads some of them if configured to do so by means of the CHECKSIG variable in the rhcd.conf file. Create a directory to hold the installation files and cd into it, then issue the command (which will download ~3Gb of data on your hard drive, for RedHat 7.3 and 8.0): $ wget -r -c -t0 -l0 --retr-symlinks -nH --cut-dirs=9 \ ftp://ftp.mirror.ac.uk/sites/ftp.redhat.com/pub/redhat/linux/updates/7.3/en/os/i386 You will probably want to change the ftp download mirror and, consequently, the parameter passed to the --cut-dirs option. That's used, in fact, together with -nH to avoid the recreation of the ftp site directory hierarchy. For more information on how to use the option correctly you can have a look at the wget documentation and man page. If you want to exclude one or more directories from the download, you can use the -X list option, where list represents a comma-separated list of directories. For example to exclude the SRPMS directory from the previous download, you would use: $ wget -r -c -t0 -l0 --retr-symlinks -nH --cut-dirs=9 \ -X /sites/ftp.redhat.com/pub/redhat/linux/updates/7.3/en/os/i386/SRPMS \ ftp://ftp.mirror.ac.uk/sites/ftp.redhat.com/pub/redhat/linux/updates/7.3/en/os/i386 This could be useful if you consider the size of the SRPMS directory (~1.2GB), or at least, I find it useful. If you want to check the GPG signatures to make sure of the authenticity of the packages (which is something I suggest) you should install the gnupg package (needed only on Redhat 7.3) and import the security@redhat.com public key you can find in the root directory of the CDs (RPM-GPG-KEY) or on the RedHat website. The key is imported by running the command: gpg --import entfilenameent in releases up to and including 7.3, which is to be changed to read rpm --import entfilenameent for release 8.0 (for more informations on this have a look at the GNU Privacy Guard and at the RPM - Redhat Package Manager websites). If you want to check the rpm packages you can do it using the following command (I'm assuming you are issuing it from the directory you have completed the downloads in): For releases up to and including 7.3: $ find . -name "*.rpm" -exec rpm -K --nopgp {} \; |grep "NOT *OK" For release 8.0 (and for future releases as well I guess): $ find . -name "*.rpm" -exec rpm -K {} \; |grep "NOT *OK" If you don't want to bother yourself with all these steps, I hope you want at least to check for the integrity of the downloaded files (which doesn't mean nobody has tampered with them), verifying the md5 signatures. This is done with: For releases up to and including 7.3: $ find . -name "*.rpm" -exec rpm -K --nopgp --nogpg {} \; |grep "NOT *OK" For release 8.0 (and for future releases as well, I guess): $ find . -name "*.rpm" -exec rpm -K --nosignature {} \; |grep "NOT *OK" The content of a Red Hat distribution does not change between releases, so you only need to download these packages ONCE. All changes to the distribution are in the updates directory. Thus, if you want to keep an up-to-date mirror of the Red Hat distribution, you only need to keep the updates directory current. This is done using the script updateDist.sh. Before using this script you have to configure the rhcd.conf configuration file and export a RHCDPATH variable pointing to the directory where this file is. $ export RHCDPATH=/home/luigi/tmp/rhcd-scripts $ sh updateDist.sh The script will download the new updates excluding the subdirectories contained in the EXCLUDELIST variable, moving the old ones (i.e. just superseded by new versions) to the directory represented by the OLDDIR variable after having completed two tests. The first test compares the .listing files generated by wget to the content of the local directories to make sure all the files were downloaded. The second test verifies the packages signatures depending on the values of the two variables CHECKSIG and USEGPG (set both of them to yes if you want the operation to be completed). In case of a failure in the signature checking process the script will move the offending packages to OLDDIR assigning them the .UPDcheckfail extension and exit without moving the old updates to OLDDIR. Mirror is a sophisticated perl script that compares the content of a directory on a remote site with a local directory. It will use FTP to fetch the files that are on the remote site but not the local site, and delete files on the local site that are not on the remote site. The mirror program is configured with a configuration file. The mirror package is available as an RPM from rufus.w3.org. Make your local copy mirror.redhat of the mirror configuration file, and edit the relevant fields at the top of the file. After the default section, define these packages: package=updates site=ftp.mirror.ac.uk exclude_patt=(SRPMS/) remote_dir=/sites/ftp.redhat.com/pub/redhat/linux/updates/7.3/en/os/i386 local_dir=/home/luigi/tmp/redhat-cd/redhat-7.3-updates package=dist site=ftp.mirror.ac.uk exclude_patt=(SRPMS/) remote_dir=/sites/ftp.redhat.com/pub/redhat/linux/7.3/en/os/i386 local_dir=/home/luigi/tmp/redhat-cd/redhat-7.3 The following command will download a copy of the entire RedHat tree on your local disk. **Think** before you do this, you are about to transfer approximately 1.5Gb of data (if you have excluded the SRPMS directory)! $ mirror -pdist mirror.redhat This will mirror the Red Hat FTP site on your local disk. The content of a Red Hat distribution does not change between releases, so you only need to download this package ONCE. All changes to the distribution are in the updates directory. Thus, if you want to keep an up-to-date mirror of the Red Hat distribution, you only need to keep the updates directory current. This is done using the command $ mirror -pupdates mirror.redhat You can run this regularly, say, once a week, through a cron script. The RedHat distribution is available on a great number of FTP servers around the world, which are updated daily from the master site at ftp.redhat.com. You should choose an FTP site close to you, see the RedHat list of mirror sites. I haven't personally tested this procedure. It was the only proposed one for the older versions of the howto (up to version 1.34, regarding RedHat ent=6.1). Nevertheless, I believe this has had, so far, much more testing than my scripts, so you want to maybe consider using it. There are three steps involved, the first two are (almost) equal in all the releases, while the last one changes quite a bit because of the changes in the anaconda installer: Correct the file protection modesReplace updated RPMsRebuild the installer To incorporate the updates, you need write access to the distribution directory from a Linux machine, with a working version of rpm installed, while to rebuild the anaconda installer you need to use a release of Redhat Linux equal to the one you are rebuilding the installer for (otherwise the procedure will fail). If you maintain a mirror of the updates directory, you can at any time produce a CD including the current updates by repeating these steps. During the installation process of the releases up to and including 6.2, some programs are run directly off the CD. Unfortunately, the FTP program does not always preserve the protection modes of the files and directories that are copied. Therefore, it is necessary to make sure that execute permission is given to programs, shell scripts and shared libraries, before the directory is burned on the CD. This is done by running the updatePerm.sh script on your local copy of the distribution. It is really needed only for version 6.2 and older, the only part useful to the 7.3/8.0 releases procedure is the directories permissions update, even if the rest won't hurt and things are kept coherent. It is almost equal to the updatePerm script included in the previous version of the howto, just some slight changes were made. Before using this script you have to configure the rhcd.conf configuration file and export a RHCDPATH variable pointing to the directory where this file is. $ export RHCDPATH=/home/luigi/tmp/rhcd-scripts $ sh updatePerm.sh The updateCD.sh script copies all the new files from the update directory to the RPMS (and SRPMS) directory. The script uses the rvc program which was presented in section to determine which packages in the updates directory are more recent. Older packages are moved to the ${OLDDIR} directory. If the CHECKSIG variable is set to yes, all the packages in the main tree will have their signature checked for correctness. If a package fails the signature check (the kind of check is configured by means of the USEGPG variable whose value is assigned in the file rhcd.conf), it is moved to the OLDDIR directory with an added extension of CDcheckfail. Before using this script, you have to configure the rhcd.conf configuration file and export a RHCDPATH variable pointing to the directory where this file is. $ export RHCDPATH=/home/luigi/tmp/rhcd-scripts $ sh updateCD.sh After having incorporated the updates in the main RedHat/RPMS directory, your copy of the distribution is no longer a mirror of the Red Hat distribution site. Actually, it is more up-to-date! Therefore, if you attempt to mirror the distribution using mirror, older versions of the RPM's that have been updated will be downloaded once more, and the updates deleted. The bash/wget based procedure doesn't suffer from the problem, but will leave the main tree in an incoherent state. Old and new packages will be in this case mixed together, but you can find and remove them wrapping the rvc binary in a simple shell script (which I will leave as an exercise for the reader...). Things have changed pretty much in this section with the introduction of the anaconda installer (as of release 6.1) and with the considerable increment in size (and ... number of CDs) the 7.x/8.0 distributions have seen. Until release 6.2, the only step composing this section was represented by generating a new hdlist file. With release 6.2, this appears to be true only to a certain extent, because of the changes in the anaconda installer, in the rpm software itself (from version 3.x to 4.x) and the migration of the updated packages to this new version (updates for release 6.2 are in fact packaged with both major releases of the rpm software). We will consider three different procedures trying to cover all the releases. When installing from the CD, the installation program on the CD relies on the file RedHat/base/hdlist describing what RPM packages are available on the CD. The hdlist file can be generated by the program misc/src/install/genhdlist. This program must be run with the absolute path to the root of the distribution as the only argument. Here is the updateHdlist script which calls that program (from version 1.34 of this howto): #!/bin/bash RHVERSION=6.1 ARCH=i386 echo generating hdlist... RHROOT=/home/luigi/tmp/redhat-${RHVERSION} GENHDDIR=${RHROOT}/${ARCH}/misc/src/anaconda/utils chmod u+x ${GENHDDIR}/genhdlist chmod 644 ${RHROOT}/${ARCH}/RedHat/base/hdlist ${GENHDDIR}/genhdlist ${RHROOT}/${ARCH} || echo "*** GENHDLIST FAILED ***" exit 0 The installation in RedHat 6.1 is completely changed from earlier versions, and RedHat has introduced anaconda. The genhdlist program is now found in a different place, so in the script above, we used GENHDDIR=${RHROOT}/${ARCH}/misc/src/anaconda/utils while for releases up to (and including) 6.0 that line should read GENHDDIR=${RHROOT}/${ARCH}/misc/src/install In some cases, genhdlist fails to run, because the executable is not statically linked. In such a case, you can add a new line ${RHROOT}/${ARCH}/RedHat/instimage/usr/lib in /etc/ld.so.conf and run ldconfig -v. Another solution is to recompile genhdlist. The following modification to the updateHdlist script worked under RedHat 5.2: #!/bin/bash RHVERSION=6.1 ARCH=i386 RHROOT=/misc/redhat/redhat-${RHVERSION} GENHDDIR=${RHROOT}/${ARCH}/misc/src/anaconda/utils echo Compiling genhdlist... sed -e 's/FD_t/int/' \ -e 's/fdOpen/open/' \ -e 's/fdClose/close/' \ -e 's/fdFileno//' ent ${GENHDDIR}/genhdlist.c ent /tmp/genhdlist.c cc -o /tmp/genhdlist -I/usr/include/rpm /tmp/genhdlist.c -lrpm -lz echo generating hdlist... chmod 644 ${RHROOT}/${ARCH}/RedHat/base/hdlist /tmp/genhdlist ${RHROOT}/${ARCH} || echo "*** GENHDLIST FAILED ***" exit 0 In this version of the script, a copy of the C source of genhdlist.c is piped through sed to create a copy in /tmp that will compile under RedHat 5.2. This version of genhdlist is then used to create the hdlist file As distributed with RedHat version 5.2 and earlier, genhdlist CRASHES if there are files in the RedHat/RPMS directory which are not RPM files! This causes problems, because in the 5.2 distribution, there are a couple of non-RPM files named ls-lR and ls-lR.gz in RedHat/RPMS. Therefore, you must remove all non-RPM files from the directory. Alternatively, you can apply the patch genhdlist.c.diff to misc/src/install/genhdlist.c and do a make. The patch will cause genhdlist to ignore any non-RPM files. You'll need to create an image file which will be written to the CD. This file will be 500Mb or more so find a partition with enough free space. You may need to be root to use mount and cdrecord. Here you will prepare the iso image of the bootable CD to be burned. It is actually, not strictly necessary, to create a bootable CD, because you could use a boot floppy instead of it, but it's definitely a nifty feature (and makes your disc more similar in behaviour to the original one). These are the commands I use to complete the task: $ mkdir /images-destination-dir $ mkisofs -r -J -T -v -V "Red Hat 6.1 (Hedwig)" \ -c boot.cat -b images/boot.img \ -o /images-destination-dir/i386-disc.iso . This is needed to burn the (bootable) disc and is executed from the top level directory of the distribution. The /images-destination-dir directory is the container for the iso image you are generating, and it must exist (obviously) before starting the procedure. In the following table you can read a brief explanation of the various options and their meanings (most of it was extracted from the mkisofs man page). -rRock Ridge extensions with useful values for the permission bits-JJoliet extensions to use the cd with some different operating systems-TGenerate a TRANS.TBL file in each directory to map correctly the file names even on systems which do not support the Rock Ridge extensions.-vbe verbose-V entvolidentSpecifies the volume ID (volume name or label) to be written into the master block.-c entboot catalogentSpecifies the path and filename of the boot catalog to be used when making an "El Torito" bootable CD. The pathname must be relative to the source path specified to mkisofs.-b enteltorito boot imageentSpecifies the path and filename of the boot image to be used when making an "El Torito" bootable CD. The pathname must be relative to the source path specified to mkisofs and specify a floppy image (which is why we use one of the floppy images found on the original CD. You may want to change this with the pcmcia.img image to install using pcmcia devices like network cards or CDROM readers.-o entfilenameentName of the file containing the generated iso image.This is the root directory for our generated iso image (we are working from the root directory of every CD, so a dot is enough). You will find details of how to burn the image on a media in . The mkisofs and cdrecord steps can be executed by means of a graphical frontend like X-CD-Roast which should currently support the creation of bootable CDs (I've never done it, so don't expect me to give you any explanation). Apparently, this is a problem child when it comes to burning an uptodate CD. The introduction of version 4 of the Redhat Package Manager (RPM), made the procedure to update the anaconda installer fail. So the procedures listed will work only if the updated packages were built using a version of the RPM software which is older than or equal to 3.0.5 (so, basically, 3.0.4 or 3.0.5). If you are using the original packages from Redhat, you have to avoid using updates released after 28 March 2001 (which is a bit useless, in my opinion) or you have to rebuild the packages using the old rpm format. Details on the downgrade procedure and tools which implement it can be found in the document rpmhack. I have not personally tested this procedure, even if it appears to work if you read about it on the anaconda-devel and kickstart mailing lists (you can find them on the mailing lists section of the Redhat website. If you decide to stick to the old original packages and complete the update (using the rpm 4.0.2 packages after the installation is finished) there are two possible ways of doing it, depending on which kind of updates you want to complete the CD with. If some of the updates regard directly the installation process (e.g. kernel, python, kudzu), you will have to use the installer rebuilding procedure explained in the document Building a Red Hat Linux 6.2 CDROM, otherwise you can still use the old procedure (the one for releases previous to and including 6.1 explained in the previous section). The last two steps, which are, respectively, creating the iso image and burning the actual media are described in and , respectively. Once again a lot of things have changed with the release of the 7.x series of the distribution. There are now more operations to complete to obtain a fresh and uptodate series of CDs. Exactly, they have become more than one with release 7.0 and now the tree has to be split to fit on the media. This is done by means of the splitdistro script, which is written in python like most of the anaconda installer. To complete this part, you must use a Linux RedHat 7.3 or 8.0 machine with the anaconda-runtime package installed (it will probably have version 7.3.7 or 8.0.4), depending on the release you want to rebuild. The procedure is composed by seven steps: Regenerating the hdlist and hdlist2 files Updating the comps.xml (or comps) file Rebuilding the installerSplitting the distribution in CD-sized chunks Regenerating the hdlist and hdlist2 files (again) Generating the iso imagesadding and checking the md5 signatures in the iso images All the steps are grouped together in a single script presented in the last section. Some of the scripts included in the anaconda-runtime package need the main tree to be moved in a subdirectory named like the architecture we are building for (so i386/ for me). We will move everything to such directory before starting the procedure and change the invocation of the scripts which don't need this modification. For redhat 8.0: $ chmod -R u+w /absolute-path-to-toplevel-dir $ mkdir -p /absolute-path-to-toplevel-dir/i386 $ cd /absolute-path-to-toplevel-dir $ /bin/mv * i386 You should change /absolute-path-to-toplevel-dir with the absolute path of the directory where the root of your local copy of the distribution is located (maybe somewhere on some hard drive). You will get an error, from the execution of the last command, because the i386/ directory cannot be moved under itself, but you don't need to worry about that. For redhat 7.3: $ chmod -R u+w /absolute-path-to-toplevel-dir $ mkdir -p /absolute-path-to-toplevel-dir/i386 $ cd /absolute-path-to-toplevel-dir $ for i in `ls` ; do [ $i != "SRPMS" -a $i != i386 ] entent /bin/mv $i i386 ; done You shouldn't receive any error message this time from the last command (hopefully). This is done by means of the following two commands with the help of the genhdlist program. $ /usr/lib/anaconda-runtime/genhdlist /absolute-path-to-toplevel-dir/i386 $ chmod 644 /absolute-path-to-toplevel-dir/i386/RedHat/base/hdlist{,2} Once again, /absolute-path-to-toplevel-dir is the absolute path of the directory where the root of your local copy of the distribution is located. The second command is needed to make sure the correct permissions are set for the file. You should already have an idea of what these files are about if you have read through . In Redhat Linux 8.0 the format of the comps file has completely changed and it's now based on XML. It provides much more flexibility and ease of customization as you can read in . If you have modified or intend to modify the list of the installed packages, you need to complete this step. This, in turn, implies having the comps-8.0.tar.gz package including the master comps file found on the Redhat website and the comps-extras rpm package installed. Follow these steps (only fo Redhat 8.0): $ cd /some-dir-of-your-choice $ tar xzvf /path-to-comps-8.0.tar.gz/comps-8.0.tar.gz $ cd comps $ make $ cat comps-milan.xml |sed 's!ent/compsent!!g' entcomps-tmp.xml $ /usr/share/comps-extras/getfullcomps.py comps.xml \ /absolute-path-to-toplevel-dir i386 entent comps-tmp.xml $ echo 'ent/compsent' entent comps-tmp.xml $ cp comps-tmp.xml /absolute-path-to-toplevel-dir/i386/RedHat/base/comps.xml Beside /absolute-path-to-toplevel-dir, you should take care of assigning valid names to /some-dir-of-your-choice and /path-to-comps-8.0.tar.gz. The rest of the commands can be just copied. Before issuing the make command, you should modify the file comps-milan.xml.in using your favourite text editor and following the guidelines and the suggestions found in and on the anaconda comps section of the Redhat website. The script presented in the last section will execute all the steps needed after the make command, using the COMPSFILE variable to find the comps-milan.xml file (it doesn't need to have that name, I'm just using the original name, but you can change it if you want). If you are using Redhat 7.3, the comps file (have you noticed the different name...) is a textual file with a completely different syntax described in some more detail in . In this case, the only necessary operations are modifying the file to suit your needs and copying it to the RedHat/base/comps file in the main tree overwriting the original one. This will rebuild the anaconda installer in your local copy of the distribution using your updated packages. $ /usr/lib/anaconda-runtime/buildinstall \ --pkgorder /absolute-path-to-toplevel-dir/pkgorder.txt \ --comp dist-8.0 --version 8.0 --release "Redhat 8.0 (Psyche)" \ /absolute-path-to-toplevel-dir/i386 Where, once again, /absolute-path-to-toplevel-dir is the directory where the root of your local copy of the distribution is located. For Redhat 7.3, the procedure is pretty much the same: $ /usr/lib/anaconda-runtime/buildinstall \ --pkgorder /absolute-path-to-toplevel-dir/pkgorder.txt \ --comp dist-7.3 --version 7.3 /absolute-path-to-toplevel-dir/i386 The absence of the (mandatory in 8.0) --release option is the only noticeable difference. This will create five directories, each one corresponding to a different CD and will put in them hard links to the real files contained in your local copy of the distribution. This will not work at all for Redhat 7.3 if you don't use the modified version of the splitdistro script reported in the next paragraph. For Redhat 8.0, a modified version of splitdistro is provided mainly because even if the problems in the previous script were fixed, the execution now fails if there are not enough packages to fill all the CDs (the first four completely and the last one even just partly). $ $/usr/lib/anaconda-runtime/splitdistro \ --fileorder /absolute-path-to-toplevel-dir/pkgorder.txt --release \ "Redhat 8.0 (Psyche)" /absolute-path-to-toplevel-dir i386 The only thing you need to change for 7.3 is the string passed to the --release option (which should be Redhat 7.3 (Valhalla)) For Redhat 7.3 the version of the splitdistro7.3 (python) script used was extracted from the anaconda-runtime 7.3.7 package and modified by me. You should sustitute it to the original one (maybe after copying the latter) named /usr/lib/anaconda-runtime/splitdistro. The only modification (apart from some small fixes), the script went through, is a change in its behaviour if the SRPMS directory is not found (doesn't terminate, but generate the CDs without source packages). For Redhat 8.0 the version of the splitdistro8.0 (python) script used was extracted from the anaconda-runtime 8.0.4 package and modified once again by me to obtain some improvements I felt the need for. You should sustitute it to the original one (maybe after copying the latter somewhere) named /usr/lib/anaconda-runtime/splitdistro. Anyway, the original one works well, if you want to build a distribution which has all the SRPMS packages (so to fill all the 5 CDs otherwise the script will fail). The only modification the script went through is a change in its behaviour if the SRPMS directory is not found (doesn't terminate failing, but generates the CDs without source packages) or there is one CD which hasn't any package on it (instead of failing, generates an empty directory). This is needed to recreate the hdlist and hdlist2 files, using some of the informations obtained in the previous steps. There are no differences between 7.3 and 8.0 for this execution of the program The command to issue is the following: $ /usr/lib/anaconda-runtime/genhdlist \ --fileorder /absolute-path-to-toplevel-dir/pkgorder.txt --withnumbers \ /absolute-path-to-toplevel-dir/i386-disc[1-3] As you can see, there are two new options passed to the program, if you remember the first run of it. The first one, --fileorder, tells genhdlist to use the file pkgorder.txt we generated in the second step (rebuild the installer). This file keeps informations on how the packages were split on the different CDs and is used by the installer to determine in which order the packages should be installed. Basically, if you avoid using it, you will (probably) end up swapping the various CDs many times during the installation. The --withnumbers option is needed to associate a CD number to every package (as you can see, a wildcard indicating the first 3 iso images is used). Here you will prepare the 5 iso images to be burned on the actual CDs. There are two different commands to be used for the first disc and for the rest of them. This is due to the need of obtaining a first CD which is bootable. This is actually, not strictly necessary, because you could use a boot floppy instead of it, but it's definitely a nifty feature (and makes your discs more similar in behaviour to the original ones). These are the commands I use to complete the task: $ mkdir /images-destination-dir $ mkisofs -r -J -T -v -V "Red Hat 8.0 (Psyche) disc 1" \ -c isolinux/boot.cat -b isolinux/isolinux.bin -no-emul-boot \ -boot-load-size 4 -boot-info-table -o /images-destination-dir/i386-disc1.iso . This is needed to burn the first (bootable) disc for RedHat 8.0 (with no floppy emulation) and is executed from the top level directory of the distribution. The /images-destination-dir directory is the container for the five iso images you are generating, and it must exist before starting the procedure. $ mkdir /images-destination-dir $ mkisofs -r -J -T -v -V "Red Hat 7.3 (Valhalla) disc 1" \ -c boot.cat -b dosutils/autoboot/boot.img \ -o /images-destination-dir/i386-disc1.iso . This is needed to burn the first (bootable) disc on 7.3 and is executed from the top level directory of the distribution (this time with floppy emulation). The rest of the images can be written by means of this for loop $ for i in `echo 2 3 4 5` ; do mkisofs -r -J -T -v \ -V "Red Hat 8.0 (Psyche) disc ${i}" \ -o /images-destination-dir/i386-disc${i}.iso . ; done The loop just presented will prepare the last four images giving them the correct numbers. As you can see, there are just two missing options from the first run, and, as you can guess, they are needed only to create a bootable CD. In , you can read a brief explanation of the various options and their meanings (most of it was extracted from the man page). This is actually an optional step but it permits the use of the checkmedia option to verify the CDs signatures before installing them, so to guarantee their correctness. The following commands permit to inject and verify an md5 signature on an iso image: $ /usr/lib/anaconda/implantisomd5 iso-image $ /usr/lib/anaconda/checkisomd5 iso-image After completing all these steps, we will find ourselves with the five CD images to burn. Considering that typing all this stuff is a bit time consuming, in the next section is presented a script, which will complete all of the listed operations in a single run (do not forget to configure the parameters properly). The updateBuild.sh script will execute all the steps needed to rebuild the distribution CDs for RedHat 7.3 or 8.0 in a single run (as root). Before using this script you have to configure the rhcd.conf configuration file after exporting a RHCDPATH variable pointing to the directory where this file is. If you want to include a modified comps.xml (or comps) file in your CDs as explained in , you should copy it into the location defined by means of the COMPSFILE variable now (before executing the script). Don't forget to add the modified splitdistro script to the /usr/lib/anaconda-runtime directory if you need it. # export RHCDPATH=/home/luigi/tmp/rhcd-scripts # sh updateBuild.sh This is composed by an optional and a required steps. Remember that, probably, you have to be root on your machine to run cdrecord . If you're paranoid, you can test your new disk image(s) by mounting it. If you forgot to fix the file permissions or set the rock ridge extensions then the error will be obvious here since the file names and directory structure will be wrong. The (optional) test can be done by issuing the command: # mount -t iso9660 -o ro,loop=/dev/loop0 iso-image /mnt/cdrom Where iso-image is the name you gave to the iso image file to be mounted (which is the only one for releases up to and including 6.2). When you're done, don't forget to unmount it # umount /mnt/cdrom Be sure to set the correct parameters for your device. This command, for example, is for a 4X CDR, which is quite slow, by the way. Moreover, it is assumed that the CD writer is on SCSI bus 0, with ID number 0 and LUN 0 (you can obtain these values by issuing a cdrecord -scanbus and assign them to the -dev= parameter). # cdrecord -v speed=4 dev=0,0,0 /images-destination-dir/disc1.img The comps file defines how the packages are bundled during the installation. In the Red Hat distribution, this is done according to the functionality they provide, for example: Printer SupportX Window SystemGNOMEKDEMail/WWW/News Tools...Kernel DevelopmentExtra Documentation Sometime during the installation process, the user is presented with a dialog called "Components to install". Some of the components have been preselected, and others not. The last item on the components list is called "Everything". On the dialog box, there is also an option that enables the user to customize exactly what packages will be installed. Customizing the installation by hand, or selecting "Everything" in the components list is the only way to have your own packages installed unless you modify the RedHat/base/comps file. The comps file currently starts with a header describing the version of the comps format, followed by an empty line. 0.1 entempty lineent After this, the components are listed, separated by empty lines: entcomponent 1ent entempty lineent entcomponent 2ent entempty lineent .... entcomponent nent entempty lineent EOF Each component has the following definition: (0|1) (--hide)? entnameent entRPM 1ent entRPM 2ent ... entRPM nent end Before the name of each component, 0 or 1 is given. A value of 1 here means that the component is chosen by default, and 0 means it's not. The option --hide means that you will not see the entry, unless you choose expert installation. The first component is called Base, and that is special, in the sense that it must be present and it does not show up in the dialog (you can't deselect the base installation, which makes sense...). Next follows a list of rpm packages belonging to that component. Note that this is the package name stored in the rpm file, and not any part of the file name of the package (although it should be the same by convention). By adding your packages to the comps file, you can customize your own distribution, and make sure that your packages will be installed by default. One thing to be careful about is interdependence among your packages, but here, you are on your own :-) A word of warning: be careful not to add or remove extra whitespace in the file. Examine the existing comps file (make a copy of the original) to see how it's done (or check i386/misc/src/install/pkgs.c if you want to see how the file is parsed). With RedHat version 6.1, the format of the comps file has changed. The decoding takes place in ${RHROOT}/${ARCH}/misc/src/anaconda/comps.py. I didn't analyze yet this python script and the following rules were obtained only by reading the file and testing some configurations for it. In release 6.1, the definition of component is extended to include some more optional elements beside the entRPMent ones. These elements are: entarch-dependent-RPM 1ent ... entarch-dependent-RPM nent entrequired-component 1ent ... entrequired-component nent entcomponent-dependent-RPM 1ent ... entcomponent-dependent-RPM nent An entarch-dependent-RPMent defines a dependency between a package and specific architecture and has the following definition: (!)?arch: entRPMent So it can, for example, present itself, in the real world, as: !alpha: kernelcfg which means: if architecture is not alpha then install package kernelcfg. Or as: i386: mkbootdisk which means if architecture is i386 then install package mkbootdisk A entrequired-component1ent enforces the dependency from another component and is defined as: @ entcomponentent So, for example, if inside a component definition you find the following line: @ Networked Workstation it means that the component itself needs the installation of another component named Networked Workstation. A entcomponent-dependent-RPMent is used to select the installation of some additional packages for a component, given the presence of another component. Its definition is as follows: ? entcomponentent { entRPM 1ent ... entRPM nent } So if, for example, in a component definition, you happen to read the following lines: ? KDE { kpppload } then if the KDE component is installed, the package kpppload will be installed together with the packages included in the component the definition was found in. With RedHat version 6.2, the format of the comps file has, apparently, changed just slightly. The decoding takes place in ${RHROOT}/${ARCH}/misc/src/anaconda/comps.py even in this case. Once again, I didn't analyze yet this python script and the following rules were obtained only by reading the file and testing some configurations for it. In release 6.2, the definition of component is extended to include two more optional elements which are: entlang-dependent-RPM 1ent ... entlang-dependent-RPM nent entarch-dependent-component 1ent ... entarch-dependent-component nent A entlang-dependent-RPMent is needed to specify the installation of a package in case a specific language was selected. It's defined as: (lang entlanguageent): entRPMent For example, the following line: (lang ja_JP)): locale-ja means: if the Japanese language is selected, then install the locale-ja package together with the other packages installed for the current component. An entarch-dependent-componentent extends the concept of entarch-dependent-RPMent introduced in release 6.1 to an entire component, as you can understand reading the definition: (!)?arch: entcomponentent With RedHat version 7.3, the format of the comps file has gained some more syntactical power. The decoding takes place (again) in the comps.py script, which you can now find in the /usr/lib/anaconda/ directory if you have installed the anaconda package. The dependencies on a language or an architecture by a component or a package can now be joined with the and operator. For example: (arch !s390 and arch !s390x and arch !ia64): readline2.2.1 which means if architecture is not any of s390, s390x, ia64 then install the package readline2.2.1. This can be done with components instead of packages and languages instead of architectures. All this, is definitely more than enough for the simple examples of customization of the default installation which will be presented in the next section. The example we will go through in this section implies modifications to the comps file to change the default values for packages installation. I usually prefer, in fact, particularly in certain situations a default installation including only the base packages, with some slight alterations to some of them. In the first of the presented examples, we will build a default installation which has the libsafe added to the Base component and most of the packages which are usually installed by default are deselected, so to build a minimal installation. In the second of the examples, we will modify some of the components to build another minimal installation which fits (this time, almost perfectly) our needs (they are, actually, my needs, your mileage may definitely vary). If you want to include a modified comps file in your CDs, you should copy it into the main tree just before starting the operations described in . To customize your installation this way, you have to edit the comps file with your favourite text editor (pay attention not to leave harmful spaces or tabs in the file) and move it to the Redhat/base directory overwriting the original one. In the first comps file included, the libsafe package was added to the Base system component and almost every component was deselected so to have a default installation comprising only two hundred packages (I know they can still be too many...). In the second comps file included, we build on the previous setup and strip down the default installation a bit more (this time there will be only 154 packages in the default installation). Some of the groups have been splitted to give the installation some more granularity. All the modifications you do should take into account the interdependencies among packages and the applications used during the installation phases (you cannot remove kudzu, for example, from the Base component, even if you can do it after installation). It must be said that similar results can be obtained using kickstart. For more informations about it, you can read The RedHat Linux Customization Guide. With RedHat version 8.0, the format of the comps file has changed completely and now an XML file, whose name is comps.xml, is used. Details on the file syntax can be found in the anaconda comps section of the RedHat website. We will now reproduce the examples presented for release 7.3 taking into account the modifications the various groups were submitted to. The most important group (the Base group) is splitted here in two groups which are named Base and Core. The Base group should represent the minimal possible installation. This time, to customize your installation you have to edit the comps-milan.xml.in file with your favourite text editor. This file can be found in the comps-8.0.tar.gz archive found on the Redhat website. To add the packages information to the file you create, you need to have the comps-extras rpm package installed. The commands to be issued to complete the operation are listed in and in the documentation. After you create the file, you have to copy it to the Redhat/base directory overwriting the original one. If you are using , you should only copy the comps-milan.xml, (after having modified the comps-milan.xml.in found in the comps-8.0.tar.gz tar/gzip package and issued the make command), to the destination you should have already configured in the COMPSFILE variable (rhcd.conf). In the first comps file included the libsafe package was added to the Base group (component) and almost every group (component) was deselected, apart from Base and Core, so to have a default installation comprising only ~220 packages (probably too many, again...). In the second comps file included, we build on the previous setup and strip down the default installation a bit more (this time, there will be only 158 packages in the default installation). Once again, similar results can be obtained using kickstart, for more informations about it you can read The RedHat Linux Customization Guide. In the example, I didn't unselect completely the installation of the Base group, because there are too many packages I usually need, so I just unselected the default installation for these packages making them optional. As you can see, even the redhat-logos package in the Core group was made optional. Considering that all of the packages in this group, together, should represent the smallest possible installation, you probably don't want to do this (by the way my CDs work even with this, there should be some failure I cannot see, yet). The tripwire package was also added to the Base group. The last noticeable modification was made to the dialup group, which will be installed even if unselected because the Base group depends on it (as declared in the group definition itself). I have selected only some packages I usually need from this group for installation and left the rest of them unselected. When installing from the new CD, you may first need to create a bootable installation diskette. IMPORTANT: use a NEW, freshly MS-DOS formatted diskette!. Using an old, worn-out, faulty diskette can result in strange problems during the installation! On a Linux system, you can create the diskette using the dd command: $ dd if=/mnt/cdrom/images/boot.img of=/dev/fd0 bs=1440k On a system running DOS or Windows-9x, you need to use the rawrite.exe program, which is found on the CD in the dosutils directory. On a machine with Windows-9x/Me/NT/2k, you can use the rawritewin.exe located in the dosutils/rawritewin directory. Shut down the machine you want to install on (or do a system upgrade), insert the boot diskette and your freshly burned CD, and let the machine boot from the diskette. For more information on the installation process, see the documents and the Installation-HOWTO or the Bootdisk-HOWTO. Most modern machines are able to boot directly from a CD, provided it is made bootable with the procedure outlined in section . Often, however, you need to change the setting of the BIOS to make the CD drive bootable. See the documentation for your mother board to see how it's done. The informations present in the previous versions of the howto (ent=1.34), and reported in the current document, which apply to releases up to and including 6.1 of Redhat Linux, is believed to apply to distributions that are Redhat clones such as Mandrake. The procedure is reported to be untested (as you can read in the howto itself) though. Similar considerations apply to the LinuxPPC distribution for Apple PowerMacs. When making a distribution for the PowerMac platform, you need to use mkhybrid) instead of mkisofs and this should be the only difference. The informations supplied for the new releases of Redhat (ent6.1) shouldn't work with Mandrake, which has now a fairly different installer from the Redhat one. I really don't know if some other clone of Redhat can have its distribution CDs updated this way, but I would be happy if you let me know. The SGML source of the most recent version of this document can be retrieved from here. The previous version, created by Morten Kjeldgaard, and Peter von der Ahent, can be found on imsb.au.dk The following documents were useful in the creation of this howto: The (unofficial) RedHat 7 Customised Installer mini-HOWTO, by Tony Nugent, that you can find on www.linuxworks.com.au Miguel Freitas has written RedHat7 CDs mini-Howto, that you can read on this website. Ron Yorston wrote the rpmhack document, relevant for release 6.2 of Redhat Linux. Someone (I couldn't find his name) wrote the document Building a Red Hat Linux 6.2 CDROM, useful for release 6.2. Ed Schlunder entzilym@asu.eduent has written a utility called fix-rhcd to let you check your Red Hat Linux distribution mirror for matching file sizes, names, permissions, and symlinks against an "ls -lNR" listing from the offical Red Hat ftp site. Any permissions that are wrong are changed to match the ls listing. See the fix-rhcd homepage. Rod Smith entsmithrod@bellatlantic.netent has written a Do-It-Yourself Red Hat Installation guide, which also includes information on creating RedHat install CD's. Especially aimed at burning a CD from a non-UNIX system. Find it on his website. A document in french Comment graver un CD de la RedHat 5.x a partir de fichiers telecharges sur Internet...'' by entskooter@hol.frent is available from linuxfr.org. With the sense of the good things in life Jussi Torhonen from Finland entjussi.torhonen@tietosavo.fient tells us Howto make a homebrew bootable RedHat Linux 5.2 CD-ROM. From the LDP project, see the CD-writing HOWTO. Apart from those mentioned above, thanks are given to the following people for valuable input, feedback, discussions and other: Morten Kjeldgaard, entmok@imsb.au.dkentPeter von der Ahent, entpahe+rhcd@daimi.au.dkentJacinta ConneelyFilippo CarcaciRiccardo Casula entriccardo.casula@inrete.itentGuillaume Lelarge entgleu@wanadoo.frent Lars Christensen entlarsch@cs.auc.dkentThomas Duffy enttbd@cs.brown.eduentDawn Endico entdawn@math.wayne.eduentSeva entseva@null.cc.uic.eduentMichael Thomas Cope entmcope@orion.ac.hmc.eduentCharles J. Fisher entcharles_fisher@bigfoot.comentEric Thomas enteric.thomas@ericsson.comentGordon Yuen entgdccyuen@yahoo.comentDave Morse entmorse@nichimen.coment