topic Slipstreaming a RHEL Installation in Operating System - Linux

Slipstreaming a RHEL Installation

Simon Hargrave — Mon, 21 Feb 2005 05:28:27 GMT

As with Windows you can create a slipstreamed CD (eg add Service Pack 2 to XP to be installed directly), I'd like to do the same with RedHat Enterprise.

We install via NFS (not CD) so we have a /install/RedHat directory containing RPMS and base directories

Periodically we download the entire RHEL3 channel from redhat and store it in a patch directory. This should be an entire distribution.

I'd like replace the RPMS directory with these patched RPMS, and use this for install.

I know I have to update the hdlist and hdlist2 files with genhdlist, that's fine. But all the documentation I've read suggests that the comps.xml needs editing too.

However, since I'm not adding "different" software, just newer software, is this necessary? It seems a very large XML file to be trawling through.

My main concern here is that clearly there will be some different files, as for example dependancies change slightly when updating a base RHEL3 installation (aspell etc). Will these need reflecting somehow in the comps.xml, and if so how?

Re: Slipstreaming a RHEL Installation

Steven E. Protter — Mon, 21 Feb 2005 05:47:22 GMT

As you are aware, RH packages patches totally different than windows or HP-UX.

I do something similar to what you want. I gather group of rpm files in a directory that depend on each other.

Then I run this code which updates all of the binaries.

installline=" "
echo "install line $installline"
for i in *.rpm
do
installline="$installline $i"
# echo "install line ... $installline $i"
done
commandline="rpm -Fvh $installline"
echo $commandline
$commandline

This should get you 75% of the way to where you want to be.

SEP

Re: Slipstreaming a RHEL Installation

Simon Hargrave — Mon, 21 Feb 2005 11:41:31 GMT

Hi, I understand this and I do a similar thing myself (however I use up2date rather than rpm -Fvh because it resolves dependancies better).

However what I'm trying to achieve is install-and-patch at once.

At present I have a Kickstart script which will install a RedHat server, including Oracle 10g and all customisations in <30 minutes. However I then have to patch it manually from the local patch repository using up2date, doubling the bare-metal to usable time.

I'd like these patches to be installed instead of the older ones and then updating. I know I could kickstart the patch install but this still takes time. I'd like to effectively create a "custom" installation that uses the new patched RPMs instead of the original ones.

There are various sources on the internet that talk of creating custom redhat CDs, but none specifically how to "fix" the comps.xml file to fully reflect the updated RPMs.

I've done a bit of experimentation since, and I've found that just updating the hdlist and hdlist2 doesn't work (it installs, but several rpms are missing).

However, I then noticed that as part of the channel update there is an rpm called (presently) comps-3AS-0.20041216 RPM which delivers an up-to-date comps.xml file. Using this alongside my genhdlist generated hdlist indexes has given me a fully patched install in < 30 minutes from bare metal.

In summary: -

Downloaded entire RHEL3 channel to /install/RedHat/RPMS
Copied /install/RedHat/base from previous install area.
Ran genhdlist to regenerate base/hdlist and base/hdlist2.

Extracted the comps.xml from comps-3AS-0.20041216 RPM and placed in the base directory.

Now installing from this directory provides an up-to-date patches server from scratch in < 30 minutes.

I will check with RedHat to see if the use of this comps.xml will always provide a "correct" installation however.

Re: Slipstreaming a RHEL Installation

Dave Falloon — Tue, 22 Feb 2005 12:39:22 GMT

Simon,

If you mess up the comps.xml just watch the install it tells you where it choked, so if you think you think you are close, run an install, if it chokes your comps is wrong, and if it installs and there are packages that were not installed you have to add them to the comps.xml.

Its a crappy yet effective way to work out the bugs.

--Dave