Bug 175341 - mkisofs alters isolinux/isolinux.bin on image causing checksum failure during boot
mkisofs alters isolinux/isolinux.bin on image causing checksum failure during...
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: cdrtools (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Depends On:
  Show dependency treegraph
Reported: 2005-12-08 19:42 EST by Kevin Fox
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-08 08:28:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kevin Fox 2005-12-08 19:42:38 EST
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:

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:
Comment 1 Harald Hoyer 2006-01-24 11:43:49 EST
how do you burn your cdrom? do you use cdrecord -dao  ??
Comment 2 Kevin Fox 2006-02-12 12:36:36 EST
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.
Comment 3 Kevin Fox 2006-02-12 13:10:10 EST
added additional bug 181191... may be related
Comment 4 Harald Hoyer 2006-02-14 05:01:29 EST
Does creating the .iso on RHEL3 and burning it on RHEL4 work?
Question is: what is broken, mkisofs or cdrecord?
Comment 5 Kevin Fox 2006-02-14 21:30:57 EST
Issue: Creating bootable iso images using mkisofs on RHEL4 fail to boot after

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.
Comment 6 Harald Hoyer 2006-02-15 02:52:20 EST
ok. thx.
Comment 7 Trevin Beattie 2006-10-12 23:18:58 EDT
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-

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
[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).
Comment 8 Trevin Beattie 2006-10-13 02:22:28 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.