Bug 770804

(In reply to comment #0)
> The final ISO file created has at least one of the RPM files corrupted.
> On tracking this down I have found that the isohybrid program is the culprit.

How did you determine this? How is the ISO image corrupted? In short, could you please provide some more details?

Some time ago, so I will try and remember.
As stated I was trying to create an updated Fedora install DVD, (actually a USB stick) using pungi. This was to contain all the Fedora16 updates plus some of our own packages to make installation on our system simple and quick (we normally do this).
This built fine, however, installing with the produced USB stick failed
installation about 7/8's of the way through due to a corrupt rpm package. After
many hours of tracking this down I found that the package RPM file in the iso image was being corrupted by the isohybrid program. I determined this by doing an "rpm -qip <package>" on the mounted iso image before and after isohybrid was run.
During tests the package that was corrupted changed with different DVD contents.
I removed the call to isohybrid in, I think, /usr/lib/python2.7/site-packages/pylorax/images.py and the DVD/USB built fine and installed fine.

Why isohybrid was corrupting the rpm package I have no idea. However, assuming
it has generally worked for people, my guess is that it had a problem with the
size of my ISO image being greater than 4GBytes (32bit limit), most users probably create live CD's or smaller install DVD's.

Probably easy to test, create a large ISO image greater than 4G containing multiple identical 100M files. Run isohybrid, and then cmp the files with the original.

(In reply to comment #3)
> Probably easy to test, create a large ISO image greater than 4G containing
> multiple identical 100M files. Run isohybrid, and then cmp the files with the
> original.

0) I've been unable to reproduce this (trying with different version of isohybrid, both 32 bit and 64 bit, running on a x86_64 system).

1) What are the version (and the release) of the syslinux package that triggers this issue? Were you running on i686 or on x86_64?

2) Do you still have, by any chance, copies of a corrupted iso and a correct iso at hand (ie, isos built with the same list of files)?

Ok, I will try and re-create it and see I the corrupted ISO's are still around (I suspect not at 4G).

It was done with a vanilla Fedora16 32bit install with all updates to 2011-12-29.

It failed on a kvm virtual machine using NFS and a VirtIO file system and also on a plain Intel Core2 system using a local hard disk.

(In reply to comment #5)
> It was done with a vanilla Fedora16 32bit install with all updates to
> 2011-12-29.

For the record: that should be syslinux 4.02-5.fc16 (see http://koji.fedoraproject.org/koji/buildinfo?buildID=260461 ).

(In reply to comment #4)
> 0) I've been unable to reproduce this (trying with different version of
> isohybrid, both 32 bit and 64 bit, running on a x86_64 system).

0) Strike that. Corruption turned out to be at the beginning of the image, not at the end (around the 4G border, were I suspected it to turn up).

1) From a (locally compiled) 32 bit version of isohybrid (running with --verbose):
[...]
imgsize: 109438976, padding: 661504
[...]

2) From the current 64 bit version of isohybrid (running with --verbose):
[...]
imgsize: 4404406272, padding: 661504
[...]

3) $ ll -tr test??.iso
-rw-rw-r--. 1 peb peb 4404406272 Jan 29 12:31 test32.iso
-rw-rw-r--. 1 peb peb 4405067776 Jan 29 12:39 test64.iso

$ dc -e "4405067776  4404406272 - p"
661504

4) Hypothesis: current isohybrid pads incorrectly (in 32 bit mode only)?

5) This commit is a likely fix (haven't tested it yet):

commit 648a240b7b69ff5f6c217c29ed46ccac5e9ad4c2
Author: P J P <pj.pandit.in>
Date:   Tue Sep 14 12:08:37 2010 +0530

    isohybrid: Use ftruncate instead of seek for final padding
    
    Pad the image via ftruncate instead of seeking to the end (which was
    done incorrectly).
    
    Signed-off-by: H. Peter Anvin <hpa>

diff --git a/utils/isohybrid.c b/utils/isohybrid.c
index 57c1015..7ee9a7f 100644
--- a/utils/isohybrid.c
+++ b/utils/isohybrid.c
@@ -543,15 +543,11 @@ main(int argc, char *argv[])
 
     if (padding)
     {
-        if (!(buf = realloc(buf, padding)))
-            err(1, "%s: could not re-size buffer", argv[0]);
+        if (fsync(fileno(fp)))
+            err(1, "%s: could not synchronise", argv[0]);
 
-        if (fseek(fp, isostat.st_size, SEEK_SET))
-            err(1, "%s: seek error - 6", argv[0]);
-
-        memset(buf, 0, padding);
-        if (fwrite(buf, sizeof(char), padding, fp) != (size_t)padding)
-            err(1, "%s: write error - 2", argv[0]);
+        if (ftruncate(fileno(fp), isostat.st_size + padding))
+            err(1, "%s: could not add padding bytes", argv[0]);
     }
 
     free(buf);

(In reply to comment #7)
> 5) This commit is a likely fix (haven't tested it yet):
> 
> commit 648a240b7b69ff5f6c217c29ed46ccac5e9ad4c2
> Author: P J P <pj.pandit.in>
> Date:   Tue Sep 14 12:08:37 2010 +0530
> 
>     isohybrid: Use ftruncate instead of seek for final padding
> 
>     Pad the image via ftruncate instead of seeking to the end (which was
>     done incorrectly).
> 
>     Signed-off-by: H. Peter Anvin <hpa>
> 
> [...]

No, that doesn't seem to help.

(In reply to comment #0)
> This is over 4GBytes ...  I suspect a 32bit pointer is being used somewhere ...

It seems this is entirely correct (but I was too dense to spot it):
[...]
imgsize: 109438976, padding: 661504
[...]

$ dc -e "4294967296 109438976 + p"
4404406272

$ ll -tr test??.iso
-rw-rw-r--. 1 peb peb 4405067776 Jan 29 12:39 test64.iso
-rw-rw-r--. 1 peb peb 4404406272 Jan 29 13:13 test32.iso

(In reply to comment #8) 
> No, that doesn't seem to help.

0) And strike that too.

1) It does seem to fix this issue. Maybe Terry (or someone else) could confirm that.

2) If confirmed, syslinux should either:
- be shipped with that patch applied;
- be shipped in version 4.03 or later (latest version is 4.05).

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.