3

I've been playing around with Kickstart on RHEL 6.2, and that involves re-mastering the install ISO. I've noticed something strange, though. If I issue the following command once (where diskFiles is the directory I've kept the DVD files)...

mkisofs -o file.iso -b isolinux/isolinux.img -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -R -J -v -T diskFiles/

...I can't create a working ISO again unless I use a fresh copy of the DVD files. Errors can range from isolinux failing to boot to Anaconda not finding the RHEL install image. So, here's my questions:

  1. Are the isolinux files within my diskFiles directory getting modified when I create the ISO?
  2. If so, what files should I replace whenever I try creating another ISO? I know copying the entire DVD over again works, but it seems unnecessary.
  3. If not, is there something I might be missing in the process that would explain this?

Essentially, my question is this: How is mkisofs doing its magic, and what does it do to the boot image in the process?

Improve this question

2 Answers 2

Reset to default
4

1 ) If the files in the diskFiles directory are being modified then this will show up with simple tools such as ls. If you have many files and or sub directories then find is your friend.

2) Rsync from a backup of the DVD will be a lot faster. I do not recommend this because it is a workaround. Finding what causes the problem is almost always better. However I recognise that sometimes a workaround is needed to get things done NOW. My experience is that these workaround stay in place forever, so avoiding them when possible is best.

(skipping item 3 because I have no answer for that).

Improve this answer
2
  • find and ls are already my friends, but they don't help me understand what's changed within a binary file. I think I need to understand more about the process within mkisofs. I'm upvoting this answer because rsync is a good idea. :-) Thanks!
    – Vishal Kotcherlakota
    May 30, 2012 at 2:50
  • 1
    I just took a fresh look at man mkisofs: -boot-info-table Specifies that a 56-byte table with information of the CD-ROM layout will be patched in at offset 8 in the boot file. If this option is given, the boot file is modified in the source filesystem, so make sure to make a copy if this file cannot be easily regenerated!
    – Hennes
    May 30, 2012 at 4:39
0

To add to the answer I accepted, there was a simple way for me to figure this out--generate a MD5 checksum! (duh.)

md5sum diskFiles/isolinux/isolinux.bin

If you were to run that command before and after invoking mkisofs, you'd see that the file is indeed changing, due to the following reason (thanks to @Hennes):

-boot-info-table Specifies that a 56-byte table with information of the CD-ROM layout will be patched in at offset 8 in the boot file. If this option is given, the boot file is modified in the source filesystem, so make sure to make a copy if this file cannot be easily regenerated!

To overcome this, I'm using the following command:

rsync -rv /home/derp/diskBackup/isolinux diskFiles/isolinux

The rsync command is much like cp, only it's much smarter and more flexible. Using this command will "clean up" the boot image files in the source filesystem, so that mkisofs can patch in the 56-byte table again without corrupting the isolinux file.

I could probably do this for the entire DVD contents, but I was too lazy to copy everything off the disc again, and isolinux is the only directory impacted by mkisofs. :-)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .