Red Hat Bugzilla – Bug 55614
RFE: Provide a way to make customized RH cd's
Last modified: 2007-04-18 12:37:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012
Description of problem:
I maintain many dozens of RedHat linux boxen. I don't need most of
the packages on the two disk set. I would like to create a single
installation cd-rom that contains only the packages I personally need.
I can create the CD layout, generate new hdlists and even modify the
comps file correctly.
But I can't figure out how to make this disc bootable.
using mkisofs and specifying images/boot.img as the el-torito
boot image fails. The error I get while booting is
Unable to identify CD-ROM format
VFS: Can't find ext2 filesystem on dev loop(7,0)
so I'm guessing it can't find the initrd.img.
Anyhow, this is not so much a "bug" as it is...
The kickstart feature is an awesome and powerful feature
for redhat. The documentation on it however is very poor.
So my bug is: radically improve the kickstart documentation.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Trying researching how to create a bootable kickstart CD-ROM
Actual Results: You'll find nothing useful. Not on redhat's site, not on other
sites, not in discussions.
Expected Results: It would be nice to have a real kickstart howto that had
various examples of kickstart methods especially customization
of RedHat distributions. The ability to customize a RedHat
distribution is a big win for RedHat.
I think the kickstart documentation is pretty complete. What kickstart features
exist that aren't covered in the documentation? I don't know of any...
I think that the docs you are requesting don't deal with kickstart specifically
as much as it does making customized Red Hat cdroms. I agree that this would be
quite useful, and we are currently thinking about the best way to do this.
If your lab is networked, the easiest thing to do is to set one server up as an
NFS, FTP, or HTTP server and then do network installs. That way, you could
remove the packages you don't need from the install tree on the server, and
those wouldn't get installed. Making modified ISOs is more complex, but I agree
that we should make this easier.
Not all my labs are networked (I often desire to use the kickstart
system at my client locations who have low-speed internet
connections so FTP and NFS (or other network) installs aren't really
an option. Plus most of my clients are very tech savy (and I'm
being kind to them here with that phrasing ;-) so I would like
to be able to produce a single custom CD for them that has the
capabilities to entirely reinstall their systems in the event of
As far as I can determine to customize such CDs you only need to
modify the following:
1) hdlist and hdlist2 (these need to be rebuilt using
/usr/lib/anaconda-runtime/genhdlist --withnumbers <base CD path>
2) you need to edit the "comps" file and remove any entries you
don't have on the CD.
3) specify a different boot image for the El Torito portion of the
CD. image/boot.img doesn't satisfy this because it appears that
the kernel from that won't be able to find the initial ram disk,
or possibly the root filesystem. I can't really figure out which.
You're right. The kickstart documentation is pretty good considering
it isn't a well advertised feature and is probably used by only a
small minority of you customers. I think it could use more of the
1) obvious corrections, like --onprimary ;-)
2) extended description of the document format and syntax.
does paramter order matter?
are blank lines ignored?
are their "special" characters? Do you need to quote paramters to
protect/use special characters?
3) more examples of %pre and %post sections. Like using %pre to perform
Anyhow, a lot of that can be discovered through trial and error or
deduced from sources on the internet.
But I can't find anything on making customized 7.2 bootable CDs. I would
be willing to write and contribute the necessary documentation on this
subject if you could walk me through process once. Basically, I have a
fully functional nfs image made by modifying the contents of the original
two CDs. How do I make a bootable image from this directory? If I could
figure that out I would write a HOWTO on it for you.
Here is what I posted some days ago to the kickstart list...
>- Make an everything install
>- Upgrade everything you can (rpm -Fv is useful)
>- Make a directory /new_version
>- Make an i386 directory in it
>- Make an SRPMS directory in it
>- Put all of both CD binaries in /new_version/i386
>- Put all of both sources CD in /new_version/SRPMS
>- Erase an replace upgraded RPMs
>- Add new ones (Omnixxxxx for example)
>- cd /usr/lib/anaconda-runtime
>- ./buildinstall /new_version/i386
>(seems to be some little problems on fonts here ... but not
>so hard to stop the process)
>- ./genhdlist --withnumbers /new_version/i386
>- PYTHONPATH=/usr/lib/anaconda ./pkgorder /new_version/i386
>i386 > PKGORDER
>- ./splitdistro --fileorder PKGORDER /new_version/ i386
>During this process we found a bug in splitdistro (which
>seems badly coded), here is a diff :
>[root@clf72av anaconda-runtime]# diff -u splitdistro
>--- splitdistro Mon Oct 22 22:34:46 2001
>+++ splitdistro.idm Wed Nov 14 19:26:38 2001
>@@ -143,7 +143,7 @@
> os.system("rm -rf %s %s %s %s" % ( disc1Dir, disc2Dir,
>-os.system("mkdir -p %s %s %s/SRPMS %s/RedHat/RPMS" %
>+os.system("mkdir -p %s %s/SRPMS %s/SRPMS %s/RedHat/RPMS" %
> (disc1Dir, disc1SrcDir, disc2SrcDir, disc2Dir))
> print "Creating disc1..."
>@@ -170,7 +170,7 @@
> print "Creating first source disc..."
>-os.system("cp -al %s/. %s" % (srcDir, disc1SrcDir))
>+os.system("cp -al %s/. %s/SRPMS" % (srcDir, disc1SrcDir))
> stamp(disc1SrcDir, "disc3", arch, startedAt)
> print "Creating second source disc..."
I gave it a try and some things do'nt work yet... But try things around
it...perhaps different parameters... I think we are not so away from finding the
solution. If you find something please make it know there
With several people looking for it... I think we can find the mean to recreate
the CDs and understand what is badly documented
Deferring to future release.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.