cd /mnt/cdrom/images dd if=boot.img of=/dev/fd0 # OR if you are installing off the net dd if=bootnet.img of=/dev/fd0
My goal is to customize the RedHat installation CD from their 7.3 official release:
Create a cdrom that already has all the update packages included
Have the Linux installation automatically follows my pre-determined settings
Specify a customized list of RPMs to install
Able to customize the virgin system further at the end of the installation
Do it all on one (1) CD.
This article is built on top of all the articles listed in the reference section. You are strongly recommended to go over all of them before go on reading this article.
Special thanks to Gray Watson, author of "Customized RedHat Linux Kickstart Installation Cdrom" and Tony Nugent ("The (unofficial) RedHat 7 Customised Installer mini-HOWTO"). Without their renovative experience, there won't be this article. More over, I've "borrowed" lots of materials from their article, sometimes even the whole paragraph is copied over. :-) If you don't have much time, you should at least read Gray's "Customized RedHat Linux Kickstart Installation Cdrom" first. It is the most clear and concise article I've read so far.
First of all, if you download the CD images from the Internet, do not burn any CD yet, instead, install Linux from a hard drive first.
mounted the cd at /mnt/cdrom
cd /mnt/cdrom/images dd if=boot.img of=/dev/fd0 # OR if you are installing off the net dd if=bootnet.img of=/dev/fd0
To make a diskette using MS-DOS, use the rawrite utility included on the Red Hat Linux CD-ROM in the dosutils directory.
rawrite asks you for the filename of a diskette image; enter the directory and name of the image you wish to write. Then rawrite asks for a diskette drive to write the image to; enter a:. Finally, rawrite asks for confirmation that a formatted diskette is in the drive you have selected.
Red Hat suggestes to use updated diskette images obtained from its Linux errata page:
http://www.redhat.com/apps/support/errata/
For more information, refer to the instructions on making the boot disk at http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/install-guide/s1-steps-install-cdrom.html#S2-STEPS-MAKE-DISKS
Choose "Hard Drive" option to install Red Hat Linux from a hard drive. Two text entry boxes for hard drive partition and hard drive directory will appear. Enter the hard drive partition that contains the ISO images (for example, /dev/hda1) in the Hard Drive Partition text box, and enter the directory that contains the ISO images in the Hard Drive Directory text box.
If you don't have enough space on your PC, the next mininum-hassle solution is to find a Linux box, loop mount the disk images and make them accessible from http. All decent Linux distro have loop mount and web server features ready for use. But a PC with a big empty HD space is strongly recommended. The following paragraph assumes that you have enough empty spaces on HD (~3G).
Caution, RH7.3 has a bug in its installation. I have no problem installing from hard drive using hda1. But when I try to reinstall the second time, RedHat refuses to list /dev/hda1. All I can choose is the Linux partitions. Darn! What sense it makes if the only places I can pick the images are those I am going to destroy?
So I recommend that you make at least two Linux volumes. One for root volume, and the other for the /export volumn. Copy the image files into the /export volumn right after the installation, in case you need to reinstall again. And preserve the /export in the following installations.
This is what I've been doing. Several small (2G) volumes for various flavor/version of Linux, and one big /export volume to share my home accross all of them. It also makes upgrading/testing the OS quite easy.
It is high time to create you own kickstart configuration file now. Kickstart allows you totally automate an installation while giving a very high degree of control over what the installer does (how partitions are created, what filesystem types to use, what packages are selected, how the box is configured, etc) by providing installer directives and hooks to run customised scripts and so on. Once you've have it, you can do reinstall whenever you want, hassle free.
The following paragraphs assumes the following directory structure is used, which is the same as mirroring the latest RedHat ftp site.
.../linux/7.3/en/os/i386 .../linux/updates/7.3/en/os/i386
This assumes that we Download lasted RedHat updates into …/linux/updates/7.3/en/os/i386, and work on our customized CD image in …/linux/7.3/en/os/i386. Please note, do not mirror/update our working directory (…/linux/7.3/en/os/i386) from the Internet. Otherwise, our work will be revoked back to the original.
Personally, I choose /export as their root directory. In the following paragraphs, I'll use the following directories for the explanation:
/export/linux/7.3/en/os/i386 /export/linux/updates/7.3/en/os/i386
I know all the people are complaining the lousy update agent that RedHat has. My experience is really dramatic: The speed I downloaded the RedHat ISO images was about 4.2Mbps. But when I was trying to use the RedHat update agent, it took my a whole day downloading 87% of the XFree86 package. Then I could not get back onto RedHat update system any more. More over, I learnt that the whole day downloading was well wasted because RedHat update agent was not able to make use of the already downloaded 87% of the XFree86 package. Further, as of May 2002, the total size of the all the i386 update packages for rh72 had bloated to almost 1100Mb (including the .src.rpms). And less than two weeks out from its official release, there are already 191Mb of updates to redhat 7.3 (kernel, evolution updates). You can't win the war in RedHat update agent. Instead, here we will never need to start the fight.
The trick is to download them, instead of updating them!
Gray Watson suggested to use "trim down" approach to select your own rpms:
Boot into Linux, loop mount the installation ISO images. Copy each of of them into the same place that you've picked.
# Load the first CD into the drive mount -o loop /sourcepath/valhalla-i386-disc1.iso /mnt/cdrom mkdir /somepath/cdrom_files cd /mnt/cdrom tar -cf - . | ( cd /somepath/cdrom_files ; tar -xvpf - ) cd /somepath/cdrom_files umount /mnt/cdrom
# Repeat the above steps for disk2 & 3. mount -o loop /sourcepath/valhalla-i386-disc2.iso /mnt/cdrom
He then went on:
"The next stage of the process is to trim down the list of packages until you get below the 700mb that will fit onto one CD. In general, I sorted the RedHat/RPMS directory by size and started at the top and moved down removing the rpms that I knew I did not need. You need to be careful here because there are dependencies between packages that aren't always expected. Someone probably has a tool to resolve dependencies but I don't know about it…
"If you rebuild the hdlist file, make the CD, and try to install and it prompts for the 2nd CD in the set then you missed a dependency. I'm not sure if or how you can tell which package is the specific problem. "
Resolve RedHat rpms' dependencies had always been a painful headache to me. More over, I haven't been paying close attention what rpm packages had been install on my system before, and what rpms I do not need. For example, I didn't know if I need the following rpms or not up until very recently: specspo, cyrus-sasl, ORBit or cURL.
So, what I did basically is to carefully select what I need during RedHat installation and include all the installed rpms in my customized CD:
cd /mnt
mkdir iso{1,2,3,4,5} rpms-org rpms-pck
mount -o loop /export/rh73/valhalla-i386-disc1.iso /mnt/iso1 mount -o loop /export/rh73/valhalla-i386-disc2.iso /mnt/iso2 mount -o loop /export/rh73/valhalla-i386-disc3.iso /mnt/iso3
cd rpms-org ln -s ../iso1/RedHat/RPMS/*.rpm . ln -s ../iso2/RedHat/RPMS/*.rpm . ln -s ../iso3/RedHat/RPMS/*.rpm .
cd ../rpms-pck rpm -qa | sed 's|^|ln -s ../rpms-org/|; s/\s*$/*.rpm ./' !! | sh
cd .. tar -h -czf rpms-pck.tgz rpms-pck
Now, I've got all the installed rpms on my system in rpms-pck.tgz file.
In practice, I hand-crafted my own kickstart configuration file to select the very rpms that I really need. For example, all tools from the "Software Development" package group, but not any "-devel" rpms from it. If you don't want to go this far (to be so prefect), following my above steps would be definitely enough.
The "add-rpm.py" in the reference section should be the perfect tool for this job, since it came out (almost) directly from RedHat anaconda. But I just couldn't make it going, even after opening up and reading the code.
So I hacked a Perl tool to update the rpms. It helps to merge RedHat official updates into our perfect RedHat installation disk. It is at http://xpt.sf.net/techdocs/linuxsm/CustomizeInstallation/tools/updateMirror.pl
Usage:
cd /export/linux updateMirror.pl i386 > updates.sh 2> updates.log
The "updates.log" shows what rpms are to be updated, and the "updates.sh" holds the actual commands to carry out the updating.
Now execute it:
sh updates.sh 2> updates.log
Now the updates.log holds the error log. It should be empty. Check with:
ls -l updates.log
If everything went on smoothly, you can remove the apt archives if you like:
rm /var/cache/apt/archives/*.rpm
If you want to backup the to-be-removed rpms, or gather would-be-copied rpms to somewhere else, refer to the program help for illustrations.
This step in optional, if you don't want a prefectly clean installation disk. At least you can safely ingore this section during your first attempt.
In the RedHat/base directory on the 1st CD is the comps file which is what anaconda reads when it displays the various packages of RPMs. It is also used used by the %packages section of the ks.cfg file. An example the comps file is:
4
1 Base {
MAKEDEV
anacron
...
}
0 --hide Network Server {
@ Network Support
(arch !i386): vnc
finger-server
? X Window System {
i386: compat-libstdc++
libpcap
}
...
}
The leading 4 means the format version of the comps file.
The "1 Base {" defines a collection of RPMs associated with the Base package. The 1 means that it is enabled by default. The "0 —hide Network Server {" defines the Network Server package which is off by default. The "—hide" means that it should be hidden from the user's package selection tool in anaconda.
The "@ Network Support" line means that the "Network Server" package includes the "Network Support" package. The "(arch !i386") line allows certain packages to be installed if (or in this case if not) installing on specific architecture. The "? X Window System {" line means that if X windows is installed then the packages in subsection are included in Network Server package.
In any case, by looking at this file, you can see which RPMs you use when you install a Network Workstation and which ones are candidates for removal if you don't install X11 stuff.
Further tuning can be done, for example to add an entry for any extra rpms that you specifically want to install:
0 --hide Extras {
numlock
xcdroast
taper
etc...
}
From "Building a kernel for AARNet Dell machines" http://www.aarnet.edu.au/redhat/build.txt
The "comps" file format is not documented, but is reasonably obvious. The mysterious "4" at the top of the file is a version number for the file format. The sections are of the basic form
<wanted> <options> <component> {
<dependency>
...
<package>
...
<optionalpackage>
...
}
Where <wanted> is 1 where the package defaults to being installed, 0 otherwise. <package> is the RPM package.
<options> ::= <nil> <options> ::= --hide
<dependency> ::= <nil> <dependency> ::= @ <component>
<optionalpackage> ::= ? <dependency> {
<package>
...
}
All lines appear to have the form
<condition>: <text>
<condition> ::= <nil> <condition> ::= !<condition> <condition> ::= <architecture>: <condition> ::= (<expr>): <expr> ::= <term> <expr> ::= <term> and <term> <term> ::= arch <architecture> <term> ::= arch !<architecture> <term> ::= lang <language> <term> ::= lang !<language> <architecture> ::= i386 | ia64 | sparc | alpha <language> ::= <lang>[_<region>[.<codeset>]] <lang> ::= ja | cs | pl | ro | sl | sk | tr | uk | ru | ... <region> ::= BR | CN | HK | TW | GB | CA | ES | ... <codeset> ::= gb2312 | ...
I've hacked another Perl tool, to clearn out from the comps file the packages that you have not selected. It is at http://xpt.sf.net/techdocs/linuxsm/CustomizeInstallation/tools/compsClean.pl. Again, this might not be necessary, Gray Watson didn't do it when building his own RH7.2.
The usage is simple:
compsClean.pl [architecture] [comps file] [path to rpms]
For example:
compsClean.pl i386 RedHat/base/comps /export/rpms/rpms-pck > /tmp/comps.new
Then you can copy the "comps.new" over the old "comps", of course after doing a diff on them.
The iso image can not be modified/updated. So we need to duplicate the first CD, and optionally do some cleaning up along the way:
cd /mnt/iso1
find . | grep -E '/(README|RELEASE-NOTES|fips[12]|images/|TRANS.TBL)' find . | grep -Ev '/(README|RELEASE-NOTES|fips[12]|images/|TRANS.TBL)' | cpio -vpdm /export/linux/7.3/en/os/i386
The file TRANS.TBL in each directory on the CDROM is used for non-Rock Ridge capable systems (e.g., MS DOS) to help establish the correct file names. They can be safely removed.
Do this to check the internal md5 checksum of each rpm package to make sure that they are all intact:
cd /export/linux/7.3/en/os/i386/RedHat/RPMS rpm -K --nopgp --nogpg *.rpm | grep "NOT OK"
In the base directory, there is the hdlist file 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 hdlist without having to read all the RPM packages which is quite convenient especially during FTP installs.
Another use of hdlist is mapping package names to file name, eg. perl to perl-5.004-6.i386.rpm. This means that if you want to incorporate updates from RedHat or add your own packages to the RPMS directory, you need to update hdlist.
Once you have removed certain RPMs from the directory and done updating rpms, you will need to rebuild the hdlist file. The file hdlist lists which RPMs are available on the first CD, and the file hdlist2 is for the second CD. You will need to build the genhdlist utility which is included in the anaconda source release. Available from any redhat mirror site, at
/…/ftp.redhat.com/linux/7.3/en/os/i386/SRPMS/anaconda-7.3-7.src.rpm
rpm -ih anaconda-7.3-7.src.rpm cd /usr/src/redhat/SOURCES tar -xjf anaconda-7.3.tar.bz2
In the utils directory in the source tarball, should be the genhdlist.c which should be buildable with make genhdlist.
cd anaconda-7.3/utils/ make genhdlist
Once you've built the genhdlist tool, go to the root path of your future cdrom system:
cd /export/linux/7.3/en/os/i386
rm -f RedHat/base/hdlist* genhdlist --withnumbers --hdlist RedHat/base/hdlist `pwd` ls -l RedHat/base/hdlist*
Please note
removing previous copy of hdlist* is vitally important. I first tried to play it safe and renamed them, but that cause me a lot of trouble.
If your pick is more than once CD, make sure to list them all, like this:
genhdlist --withnumbers --hdlist RedHat/base/hdlist `pwd` /mnt/iso2 /mnt/iso3
This is optional. It requires a tools listed in the later "Helpful tools" part. I include them here to show how I did the test. The reason doing this is that hdlists are binary files. You can't compare them directly.
dumphdrlist.py RedHat/base/hdlist | less
dumphdrlist.py /mnt/iso1/RedHat/base/hdlist > /export/baks/hdlist.o1 dumphdrlist.py /mnt/iso1/RedHat/base/hdlist2 > /export/baks/hdlist.o2
dumphdrlist.py /export/linux/7.3/en/os/i386/RedHat/base/hdlist > /export/baks/hdlist.n1 dumphdrlist.py /export/linux/7.3/en/os/i386/RedHat/base/hdlist2 > /export/baks/hdlist.n2
diff -wu /export/baks/hdlist.o1 /export/baks/hdlist.n1 | less diff -wu /export/baks/hdlist.o2 /export/baks/hdlist.n2 | less
This is probably the best feature of all, and something which there is no direct equivalent to in the manual installation process. What we can do here is specify a sequence of shell level commands which should be executed after the main installation (disk partitioning, package installation, and so on) is complete.
If you need to copy files off of the install media to the new installation then you'll need to do something like the following:
%post --nochroot # the --nochroot is necessary to not change root into the new installation # cp /mnt/source/dir/file /mnt/sysimage/dir/file # where /mnt/source is the install media # and /mnt/sysimage is the new installation
# Use my very own profile cp /mnt/source/customized/profile /mnt/sysimage/etc/profile # My extra can't-live-without tools cp /mnt/source/customized/opt.tgz /mnt/sysimage/
The beginning of this section is signified by the %post directive in the KickStart config file. In what follows you can take advantage of all of the utilities which have been installed on your newly built Linux system, and operated on the real root file system.
For example, setup crontab jobs by creating root crontab entries as files in one or more of the directories /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly.
Mine is:
%post
# turn off packages that we don't want running echo Turning off some packages /sbin/chkconfig --level 0123456 isdn off /sbin/chkconfig --level 0123456 nfslock off
echo Turning on some packages /sbin/chkconfig --level 345 httpd on /sbin/chkconfig --level 345 postgresql on /sbin/chkconfig --level 345 rsync on /sbin/chkconfig --level 345 wu-ftpd on
echo Change firewall from ipchains to iptables chkconfig --level 12345 ipchains off chkconfig --level 345 iptables on
/bin/bash -c 'rm -f /root/.bash_logout'
/bin/echo "/opt/bin/guide &" >> /etc/rc.d/rc.local
Refer to Tony's article for a full script creating iso9660 disk images. Also available at my local copy "Bare bone RedHat 7 Customised Installer" http://xpt.sf.net/techdocs/linuxsm/CustomizeInstallation/linuxsm01.003.html#section-1.
Note, mkisofs will show the following warning:
Warning: creating filesystem that does not conform to ISO-9660. Using XFREE000.RPM for RedHat/RPMS/XFree86-ISO8859-15-100dpi-fonts-4.2.0-8.i386.rpm (XFree86-100dpi-fonts-4.2.0-8.i386.rpm) Using XFREE001.RPM for RedHat/RPMS/XFree86-100dpi-fonts-4.2.0-8.i386.rpm (XFree86-4.2.0-8.i386.rpm)
This is normal, because we are generating Joliet directory records in addition to regular iso9660 file names. Also, we will have long file names on CD (e.g., XFree86-100dpi-fonts-4.2.0-8.i386.rpm) instead of short ones like XFREE000.RPM. Use the technique in the next topic to verify it.
If you're paranoid you can test your new disk image 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.
mount -t iso9660 -o ro,loop=/dev/loop0 /tmp/redhat.img /mnt/cdrom
When you're done, don't forget to unmount it.
You might want at some point to make a full distribution CDROM set that contains all tools from RedHat official distribution, while having all new rpms updated. If so, go on to read Tony Nugent's "The (unofficial) RedHat 7 Customised Installer mini-HOWTO", listed in the following reference section. You may also want to check out my local copy "Bare bone RedHat 7 Customised Installer" if you find his a bit overwhelming at first. http://xpt.sf.net/techdocs/linuxsm/CustomizeInstallation/linuxsm01.003.html#section-1.
But for me, those "ten easy steps" are still too difficult. I dare not to try. Instead, I put all the remaining rpms on another CDROM, and make it also bootable. As Tony said, "why waste a useful feature of a cdrom? If there is space (and not much is needed), there is no reason why you couldn't manually add your own cdrom boot images to them."
I chose the "Tom's Root Boot Disk" (http://www.toms.net/rb/), 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).
Although this article comes as a whole, it does not mean that you have to take all the steps at once. Instead, you are strongly suggested to take steps as minimum as possible. For example, try make your kickstart configuration file, and test it with the installation first. Actually this is a BIG step already. I spent over a week to make my perfect kickstart configuration file. Try the out of box anaconda-ks.cfg without any modification first. Then make your modification step by step, and keep the copy of all the versions, in order to be able to roll back on failure.
You can't be more careful when doing this, because you've entered the most buggy world of RedHat. Be prepared for it. You are warned.
If you do meet with problems, ask youself if you have made the best effort to kept you step minimum. Can it be split even further? When it can boil down to only one single change, you chance to find out what is wrong will be bigger.
You can also browse all the collections I've made. It will save you a lot of time trying to find them. I think I've covered at least 90% of the related articles from the web and newsgroups by the time this article is prepared. If you meet with some problem that is not covered here, you might be doing something wrong. I can't help you with your specific problem. Please refer to the previous paragraph for the solution. Or better, bug the RedHat for the solution. :-) Last by not least, people in the comp.os.linux.misc newsgroup are generally helpful. You are welcome to fire up open discussions in it. I watch this newsgroup closely.
Note,
If any of above links does not work by the time you read this article, you can find a local copy here:
http://xpt.sf.net/techdocs/linuxsm/CustomizeInstallation/mirrored
Joshua Sarro <mthed@shore.net> has contributed a perl script called updateMirror.pl that copies all files from the update directory to the RPMS directory. The script uses some nifty rpm tricks to determine what packages in directory. The "kernel" packages that come in several flavors are also preserved (Certain RPMs, specifically the kernel and kernel-smp packages, include the platform in the filename but not in the package name). You can fetch it here: http://imsb.au.dk/~mok/linux/doc/updateMirror.pl.
Also, Anaconda offers some tools that help to ensure that things are ok.
The python script /usr/lib/anaconda-runtime/check-repository.py can be used to check the RedHat/base/comps file to ensure that it is consistent with the contents of the RedHat/RPMS/ directory. However, comment out the "import todo" entry (around line 38) before you use it. (Thanks to Forrest Taylor <forrestx.taylor@ intel.com> for this hint).
Seth has some more gems available at http://www.dulug.duke.edu/treetools/…
comps-check.pl is "not terribly pretty but it seems to work… for MOST situations. You pass it an architecture a comps file and a dir of rpms - it hands you back whats in the comps file thats missing from the dir of rpms for that arch. http://www.dulug.duke.edu/treetools/comps-check.pl http://www.linuxworks.com.au/comps-check.pl.txt
the add-rpm.py adds updated rpms to an install tree. http://www.dulug.duke.edu/treetools/add-rpm.py http://www.linuxworks.com.au/add-rpm.py.txt
depchecktree.py just takes the dirs you give it, look for all the rpms and tells you if they fully satisfy their dependencies. http://www.dulug.duke.edu/treetools/depchecktree.py http://www.linuxworks.com.au/depchecktree.py.txt
dumphdrlist.py is a python script written by Jeremy Katz (<katzj@redhat.com>) that looks at the RedHat/base/hdlist file and lists which installation disk a particular rpm is on. From Jeremy: "Usage is simple enough — 'dumphdrlist.py /path/to/hdlist' and it will then print the NEVRA of all of the packages as well as the disc it's on in the format" http://www.linuxworks.com.au/dumphdrlist.py.txt
RedHat Linux comes with a feature called KickStart. This feature lets you automate most/all of a RedHat Linux installation.
It lets you create a single file (ks.cfg) which contains the answers the all the questions that would normally be asked during a typical RedHat Linux installation.
It does standardized installations, but also can tolerate a certain amount of hardware differences: e.g., NIC, Video, Hard drive sizes, etc.
All the kickstart howtos/documents throw too much detail information to me. You get frustrated very quickly: "kickstart should be simple, why there is no simple explaination for a simple task?". Now, here is the simplest way you can make use of kickstart feature:
Use the command ksconfig to produce one. It will help you understand what those lines mean. Hint: use the "save file…" often, to preview the result.
Merge in whatever you think valuable from \root\anaconda-ks.cfg. This is how your current Linux is installed.
Copy it to any MS-DOS floppy, naming it "ks.cfg". Yes! any DOS disk will do, not necessarily a Linux Boot disk!
Then, boot off your RH cdrom. At syslinux boot prompt type:
linux ks=floppy
That's it. Vola!
Prepare as many kickstart config files as you want, store them all in one floppy disk. Hand pick one that is most suitable for your installation situation. Suppose I name my fully automatic lab installation kickstart config file (that automatically partition and install Linux on the system) as ks-lab1.cfg. At boot prompt type:
linux ks=hd:fd0/labs/ks-lab1.cfg
Then go for a sip of coffee, everything would be in perfect shape when you return.
Note, you can only put kickstart config files on floppy disk if you are not booting from it. Otherwise, you'll get an error saying kickstart file not found. (Tested on RH7.3, as of 2002.08.29 Thu)
If you are booting from floppy, copy the kickstart config files to your hard disk, then issues the following:
linux ks=hd:hda1/rh73/ks1.cfg
If you are happy with your choices, click the Save File button within the dialog box. A save file dialog box will appear and allow you to choose where to save the file. The default file name to save it as is ks.cfg. Copy the kickstart file (ks.cfg) on a floppy disk.
Boot from the disk and type linux ks=floppy to start the kickstart installation. To learn about different methods for starting a kickstart installation refer to the Official Red Hat Linux Customization Guide.
clearpart --linux part / --fstype ext3 --onpart hda3 part swap --onpart hda2 part /export --fstype ext3 --onpart hda4
clearpart --linux part swap --size=384 --asprimary part / --fstype ext3 --size=2200 --asprimary part /export --fstype ext3 --size=1 --grow --asprimary
Normally it would take many time of try-and-errors before you can have a good and working copy of ks.cfg. To make things easier, do not burn and cd when trying. Otherwise, it is a waste of time and your cd. Install from hard drive images instead!
A lot of information is made available during the installation process on alternate consoles. Press ALT and a function key to switch to a different console. This is especially useful if the installation fails. E.g., a kickstart installation will fail if a package in the list of those to install is not available. If it does happen, at least you can get more detailed error messages this way, or even a shell.
Console 1 (ALT-F1): graphical installation status (what's normally shown during installation).
Console 2 (ALT-F2): bash shell (once the installation has progressed far enough).
Console 3 (ALT-F3): Installation progress log, including module insertion. The cause of an error can often be found here.
Console 4 (ALT-F4): Appears to be a log of raw device/SCSI information.
Console 5 (ALT-F5): Appears to be a log of filesystem operations.
Exerpted from "The (unofficial) RedHat 7 Customised Installer mini-HOWTO " http://www.linuxworks.com.au/redhat-installer-howto.html This is a shrinked down version, with some of my annotations.
My basic approach and aim here is to create customised rh7.x installation cdroms that have already had all the update packages added to them.
STOP! before read on, please check out the The RULE Project (Run Up2date Linux Everywhere). http://www.rule-project.org/index.html
Make Red Hat Linux installer runs in less than 32 MB of RAM
Select, test, and (if needed) package the system and desktop applications which give the greatest real functionality with the smallest consumption of CPU and RAM resources
Create another installation, containing all and only the packages above, optimized to run either a server, or a basic desktop on obsolete hardware with very little RAM and HD space.
We have to choose one package for each specific task (be it a server or desktop one) according to the following guidelines.
It must be actively developed, compiled with modern, secure libraries, with as little as possible known security holes.
The most recent stable version must be used, without any specific patches
more on
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.
As of May 2002, the total size of the all the i386 update packages for rh72 had bloated to almost 1100Mb (including the .src.rpms).
And less than two weeks out from its official release, there are already 191Mb of updates to redhat 7.3 (kernel, evolution updates).
Repeatedly applying all that lot to every new installation is a real headache… kernels (generally) need to be installed and not upgraded or freshened (although this has recently changed), some packages are new and need installing before some of the updates, you need to choose between freshening with 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.
Kickstart allows you totally automate an installation while giving a very high degree of control over what the installer does (how partitions are created, what filesystem types to use, what packages are selected, how the box is configured, etc) by providing installer directives and hooks to run customised scripts and so on.
Kickstart is an integral part of the anaconda installer, they go hand-in-hand. If you use kickstart, you are using anaconda. If you are building deployment distributions with the anaconda tools, you are neglecting some of its most powerful features if you don't consider using kickstart to script its behaviour.
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
Now get rid of any messy "leftovers" that came with the cdrom… The ugly TRANS.TBL files can go, so can boot.cat (on bootable cdroms) and any rr_moved/ directories that may have been copied over:
# find /redhat/i386 -name TRANS.TBL -o -name rr_moved -o -name boot.cat -exec rm -rf {} \;
Do this to check the internal md5 checksum of each rpm package to make sure that they are all intact:
cd /redhat/i386/RedHat/RPMS rpm -K --nogpg *.rpm | grep "NOT OK"
Bugfix updates to the anaconda installer are periodically released. They come as floppy disk images, used from the installer if you tell the bootloader to use it by giving it the appropriate parameters. The installer then asks for the floppy disk, you put it into the floppy drive and away it goes.
The only updates to redhat 7.3 so far involve replacement packages, no new ones. The comps file does not need to be modified from its default.
Anaconda offers some tools that help to ensure that things are ok.
The python script /usr/lib/anaconda-runtime/check-repository.py can be used to check the RedHat/base/comps file to ensure that it is consistent with the contents of the RedHat/RPMS/ directory. However, comment out the "import todo" entry (around line 38) before you use it. (Thanks to Forrest Taylor <forrestx.taylor@ intel.com> for this hint).
Seth has some more gems available at http://www.dulug.duke.edu/treetools/…
comps-check.pl is "not terribly pretty but it seems to work… for MOST situations. You pass it an architecture a comps file and a dir of rpms - it hands you back whats in the comps file thats missing from the dir of rpms for that arch. http://www.dulug.duke.edu/treetools/comps-check.pl http://www.linuxworks.com.au/comps-check.pl.txt
the add-rpm.py adds updated rpms to an install tree. http://www.dulug.duke.edu/treetools/add-rpm.py http://www.linuxworks.com.au/add-rpm.py.txt
depchecktree.py just takes the dirs you give it, look for all the rpms and tells you if they fully satisfy their dependencies. http://www.dulug.duke.edu/treetools/depchecktree.py http://www.linuxworks.com.au/depchecktree.py.txt
dumphdrlist.py is a python script written by Jeremy Katz (<katzj@redhat.com>) that looks at the RedHat/base/hdlist file and lists which installation disk a particular rpm is on. From Jeremy: "Usage is simple enough — 'dumphdrlist.py /path/to/hdlist' and it will then print the NEVRA of all of the packages as well as the disc it's on in the format" http://www.linuxworks.com.au/dumphdrlist.py.txt
FIXME: here (?) add details of more scripts and utilites that:
can be used to easily and sanely update (replace, add or remove packages) an installation image from a local (or remote) updates repository.
will make package dependency checks on the RedHat/RPMS/ directory and then create a new comps file based on the original one, and on what has been added or removed from the RPMS/ installation directory.
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.
You want a distribution CD containing the latest distribution with all current updates, and only your selection, on to one single disk.
Mostly the information bellow is hacked from "Burning a RedHat CD HOWTO" http://imsb.au.dk/~mok/linux/doc/RedHat-CD.html
The toplevel directory for RedHat Linux release contains distributions for the different platforms, and a directory containing updates and corrections to program packages that have been published since the release.
The images directory contains boot floppy images that must be copied to a diskette. The boot image is called boot.img, which is required when installation is performed directly from a CD-ROM. If installation from a local hard disk, NFS mounted disk or FTP is required, the supplementary disk image supp.img might be needed.
The misc directory contains source and executables of a number of programs needed for the installation. Finally, the iso directory contains iso9660 images just like the one you we about to make.
The most important part of the directory tree is 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 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 RPM packages for more information.
The base directory holds different book-keeping files needed during the installation process, e.g. the comps file, which defines the components (groups of packages) used during the "Choose packages to install" phase. See section The comps file for more information on this file, and how to use it. Another important file in the base directory is the hdlist file 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 hdlist without having to read all the RPM packages which is quite convenient especially during FTP installs.
Another use of hdlist is mapping package names to file name, eg. perl to perl-5.004-6.i386.rpm. This means that if you want to incorporate updates from RedHat (see section Incorporating the updates) or add your own packages to the RPMS directory, you need to update hdlist. This is descriped later in Generating a new hdlist file.
The instimage directory contains a bare-bones live file system with a number of programs and shared libraries needed during the installation procedure.
Correct the file protection modes.
Replace updated RPMs.
Generate the hdlist file
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, 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 script on your local copy of the distribution:
Joshua Sarro <mthed@shore.net> has contributed a perl script called updateMirror.pl that copies all files from the update directory to the RPMS directory. The script uses some nifty rpm tricks to determine what packages in directory. The "kernel" packages that come in several flavors are also preserved (Certain RPMs, specifically the kernel and kernel-smp packages, include the platform in the filename but not in the package name). You can fetch it here: http://imsb.au.dk/~mok/linux/doc/updateMirror.pl.
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:
#!/bin/bash
RHVERSION=6.1 ARCH=i386
echo generating hdlist...
RHROOT=/jaz/redhat-${RHVERSION}
GENHDDIR=${RHROOT}/${ARCH}/misc/src/install
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 have introduced a system called “anaconda”. The genhdlist program is now found in a different place, so in the script has changed in GENHDDIR.
The above script has some problems when used for an architecture other than the machine you are on. For instance a person on an i386 machine couldn't # correctly build the sparc hdlist.
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 Support X Window System GNOME KDE Mail/WWW/News Tools ... Kernel Development Extra 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.
On the dialog box, there also is 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.
With RedHat version 6.1, we have not yet disected it to discover the file format. With the bellow information, however, it should be easy enough to do it yourself. The decoding takes place in
${RHROOT}/${ARCH}/misc/src/anaconda/comps.py.
The format of the comps file currently starts with a header describing the version of the comps format, followed by an empty line.
0.1 <empty line>
After this, the components are listed, separated by empty lines:
<component 1> <empty line> <component 2> <empty line> . . <component n> <empty line> EOF
Each component has the following definition:
(0|1) (--hide)? <name> <RPM 1> <RPM 2> ... <RPM n> 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 is often the same).
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).
Make sure the top directory of the CD contains at least the following files and directories:
COPYING RPM-PGP-KEY README RedHat/
The following directories might come in handy:
doc/ gnome/ misc/ dosutils/ images/
If you're paranoid you can test your new disk image 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.
mount -t iso9660 -o ro,loop=/dev/loop0 /tmp/redhat.img /mnt/cdrom
When you're done, don't forget to unmount it.
umount /mnt/cdrom
This perl script to extract a list of rpms from the /RedHat/RPMS directory on the cdrom. I only had about 6 corrections to make and figured it would take me longer to fix the perl script that it would be to fix the list.
#!/usr/bin/perl
while(my $Rpm = <>){
if ($Rpm =~ /\-[0-9]+\-[0-9]+\./)
{($Rpm,$Junk) = split(/\-[0-9]+\-[0-9]\./, $Rpm,2);}
elsif ($Rpm =~ /\-[0-9]+\./)
{($Rpm,$Junk) = split(/\-[0-9]+\./, $Rpm,2);}
else {($Rpm,$Junk) = split(/\-[0-9]/, $Rpm,2);}
print $Rpm\n";
}