我一直在使用RHEL 6.2上的Kickstart，并且涉及重新安装ISO。 不过，我注意到了一些奇怪的东西。 如果我一次发出以下命令（其中diskFiles是我保存DVD文件的目录）…
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/
…除非我使用DVD文件的全新副本，否则我无法再创build一个可用的ISO。 错误可能从isolinux无法启动到Anaconda找不到RHEL安装映像。 所以，这是我的问题：
diskFiles目录中的isolinux文件是否被修改？ 本质上，我的问题是这样的： mkisofs是如何做到这一点的，它在这个过程中对引导映像有什么作用？
1）如果diskFiles目录中的文件正在被修改，那么这将显示与简单的工具，如ls 。 如果你有很多文件和/或子目录，那么find你的朋友。
2）来自DVD备份的Rsync会快很多。 我不build议这样做，因为这是一种解决方法。 找出导致问题的原因几乎总是比较好的。 不过，我认识到有时需要一个解决方法来完成现在的事情。 我的经验是，这些解决方法永远保持在原地，所以尽可能避免它们是最好的。
（跳过项目3，因为我没有答案）。
为了增加我接受的答案，我有一个简单的方法来解决这个问题 – 生成一个MD5校验和！ （杜）。
md5sum diskFiles/isolinux/isolinux.bin
如果你在调用mkisofs之前和之后运行这个命令，你会发现这个文件确实在改变，原因如下（感谢@Hennes）：
-boot-info-table指定包含CD-ROM布局信息的56字节表格将在引导文件的偏移量8处打补丁。 如果给出这个选项，引导文件在源文件系统中被修改，所以如果这个文件不能被容易地重新生成，一定要做一个拷贝！
为了克服这个问题，我使用下面的命令：
rsync -rv /home/derp/diskBackup/isolinux diskFiles/isolinux
rsync命令非常像cp ，只是它更聪明，更灵活。 使用此命令将“清理”源文件系统中的引导映像文件，以便mkisofs可以在不损坏isolinux文件的情况下重新打包到56字节的表中。
我可以为整个DVD内容做这个，但是我懒得把所有的东西都复制下来， isolinux是唯一受mkisofs影响的目录。 🙂