From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041215 Firefox/1.0 Red Hat/1.0-12.EL4 Description of problem: using mkisofs to create bootable iso files alters the isolinux/isolinux.bin in such a manner that it fails to pass the checksum when attempting to boot the recorded iso image. Issue appeared when upgrading from rhel 3 to rhel 4. have made several attempts to test on different arch. and release versions of rhel 4. all iso images produced with rhel 4 failed to boot. Boot message on rhel 4 iso tests: ISOLINUX 2.XX 200X-XX-XX isolinux : Image Checksum error, sorry... Boot Failed: press a key to retry Tested building iso using rhel 3 mkisofs on several arch and releases all iso images booted succesfully Version-Release number of selected component (if applicable): All RHEL 4 x86 / x86_64 releases of mkisofs How reproducible: Always Steps to Reproduce: 1. burn cd attempt to boot 2. write cd iso attempt to boot vmware virtual machine using iso image file. 3. write cd iso image attempt to boot image file on remote server using virtual media Actual Results: iso images produced using rhel 4 mkisofs fail to boot. command syntax for creating image mkisofs -J -R -T -v -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o ../test.iso . Expected Results: iso image boots Additional info:
how do you burn your cdrom? do you use cdrecord -dao ??
Tested both methods of burning -dao and -sao error continues to exist. I am using RHEL4 U2. Please note this command sequence works for with RHEL3 UX.
added additional bug 181191... may be related
Does creating the .iso on RHEL3 and burning it on RHEL4 work? Question is: what is broken, mkisofs or cdrecord?
Issue: Creating bootable iso images using mkisofs on RHEL4 fail to boot after burning. Burning iso images created on RHEL 3 using RHEL 4 works fine. However iso images created using mkisofs on RHEL4 and burned on RHEL4 complete successfully but the image will not boot. The problem is with mkisofs. It seems to be changing isolinux when it writes the iso file.
ok. thx.
I wonder if this is related to the problem I just discovered? I recently burned a disc where some of the files appeared to be corrupt. Tonight I mounted the ISO image and compared the files in the image to the originals, and diff reported several of the large files were different. So I re-ran mkisofs to create the ISO image again, did another comparison, and one of the previously corrupted files turned out OK that time but the rest were still corrupted. I ran mkisofs a third time, this time running 'sync' during and after the image creation. This last time the entire disc contents compared identical. I'm using Fedora Core 6 RC2, which has mkisofs-2.01.01.0.a10-1.1. It's also conceivable that this problem may not be mkisofs' fault, but a deeper problem with the kernel filesystem code. Just yesterday I had a problem with an I/O error after reading about 600MB of a 1.1GB file. The kernel message was: Oct 11 19:18:26 hydra kernel: attempt to access beyond end of device Oct 11 19:18:26 hydra kernel: md1: rw=0, want=6298100090, limit=435441536 Oct 11 19:18:26 hydra kernel: Buffer I/O error on device md1, logical block 3149 050044 [repeats several dozen times with different 'want' and logical block values] I don't know what that logical block number means -- md1 is a 200GB RAID-1 volume. I dropped into single-user mode and ran e2fsck over the volume, but it found zero errors. I then tried reading the same file again, and it read all 1.1GB without any problem. So I assume something was corrupt in buffer memory. The kernel I'm running is 2.6.17-1.2630.fc6 (from FC6 RC3).
Additional follow-up info: I just checked an older ISO image that I had created a month ago and found that it, too, has a couple of corrupted files. I re-created the ISO image while periodically running sync, but that didn't fix it -- one of the previously corrupted files was fixed, but another file which was previously good got corrupted. Another pass fixed that file but left one file still corrupt. The next pass corrupted three more files. Finally I tried transferring the files to another computer (running RHEL3) so that I could create the ISO image there instead. Guess what -- the files failed to compare on the two computers right after an rsync! I'm even getting different md5sum checksums on repeated checks of the same files; it seems to depend on what group of files I run m5dsum over, and changes only when I try to verify several gigabytes of data. (My system has 4GB RAM.) I don't think this is a mkisofs problem at all.