Bug 175341

Summary:	mkisofs alters isolinux/isolinux.bin on image causing checksum failure during boot
Product:	Red Hat Enterprise Linux 4	Reporter:	Kevin Fox <kevin.j.fox>
Component:	cdrtools	Assignee:	Harald Hoyer <harald>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.0	CC:	trevin
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-03-08 13:28:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kevin Fox 2005-12-09 00:42:38 UTC

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:

Comment 1 Harald Hoyer 2006-01-24 16:43:49 UTC

how do you burn your cdrom? do you use cdrecord -dao  ??

Comment 2 Kevin Fox 2006-02-12 17:36:36 UTC

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 18:10:10 UTC

added additional bug 181191... may be related

Comment 4 Harald Hoyer 2006-02-14 10:01:29 UTC

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-15 02:30:57 UTC

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.

Comment 6 Harald Hoyer 2006-02-15 07:52:20 UTC

ok. thx.

Comment 7 Trevin Beattie 2006-10-13 03:18:58 UTC

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).

Comment 8 Trevin Beattie 2006-10-13 06:22:28 UTC

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.