similar to: [PATCH] isohybrid: fix overflow on 32 bit system

When call isohybrid with option '-u', it overflows on a 32 bits host. It seeks to 512 bytes before the end of the image to install gpt header. If the size of image is larger than LONG_MAX, it overflows fseek() and cause error: isohybrid: wrlinux-image-x86-64-20140505110100.iso: seek error - 8: Invalid argument Check the offset and call fseek() multi-times if offset is too large.

On 2014?05?12? 22:38, H. Peter Anvin wrote: > That is because it needs to use fseeko() and use off_t. Do you mean it does need a patch for isohybrid.c. And the patch looks like: #if _FILE_OFFSET_BITS == 64 fseeko(...) #else fseek(...) Regards, Kai > > On May 11, 2014 11:53:17 PM PDT, Kang Kai <Kai.Kang at windriver.com> wrote: >> On 2014?05?12? 10:49, H. Peter

On 2014?05?12? 10:49, H. Peter Anvin wrote: > On 05/11/2014 06:56 PM, Kai Kang wrote: >> When call isohybrid with option '-u', it overflows on a 32 bits host. It >> seeks to 512 bytes before the end of the image to install gpt header. If >> the size of image is larger than LONG_MAX, it overflows fseek() and >> cause error: >> >> isohybrid:

It seems unwise to offer future programmers fseek(3) calls for copy+paste. They are simply insufficient for large image files. This change switches all calls of fseek(3) to fseeko(3) and takes care that the offset value if of type off_t. --- utils/isohybrid.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/utils/isohybrid.c b/utils/isohybrid.c index

Hi, following will be 6 patch proposals for isohybrid.c 1: Encode GPT partition names as UTF-16LE 2: Correct blocking factor in APM partition block counts 3: Correct end block address of first GPT partition 4: Write GPT backup to the very end of the image 5: Change all fseek(3) to fseeko(3) 6: Introduce option --mbr and make isohybrid.c compilable standalone If the form needs adjustments,

The GPT backup header block should start 512 bytes before the end of the image file (resp. end of the disk device). This block and the backup GPT array were wrongly written 512 bytes too early. This change brings the backup GPT at its correct position. --- utils/isohybrid.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/utils/isohybrid.c b/utils/isohybrid.c index

EFI systems typically don't support booting off ISO 9660 filesystems, even if written to USB sticks. This patch adds support for generating a GPT that covers the stick as well, with an additional partition entry pointing purely at the secondary El Torito image. When burned to CD the secondary El Torito will be used as an EFI boot image, and when written to a USB stick the GPT partition

Hello Recently while playing with bigger iso images (>2G) looks like isohybrid from syslinux-4.02 fails. Sometimes tunning heads/sectors (-h/-s) works, because no padding is needed depending of size of the image. Some debug info provided, if more info is needed please just ask. # isohybrid -v pandereta-2010.09.13-i686.iso catalogue offset: 326 ve[0]: 1, cs: 1 ve[1]: 0, cs: 1 ve[2]: 25927,

> Hi, > > > All the "isohybrid.exe" I know of are based on the Perl variant. > > I just got one from > http://www.filewatcher.com/m/isohybrid.exe.39568-0.html > > Its strings seem not to stem from isohybrid.pl. > > Digging in slitaz source brought a shell script (that would be > variant #5 then): >

Hi, hpa: > The right thing to do is compile it with #define _FILE_OFFSET_BITS 64 > and change fseek to fseeko with the appropriate type being off_t. And for GPT names it should really use 16-bit UTF-16LE characters and not 8-bit characters padded up by the same number of random bytes from the program memory. See e.g.:

Hi, i am currently exploring the boot data of Matthew Garret's Fedora LiveCD. For that i read utils/isohybrid.c from git resp. 4.05. (I assume Matthew used options --efi --mac --type 0 .) Some stumblestones showed up: ----------------------------------------------------------------------- In initialise_gpt() i see unhealthy usage of string constants. Like: memcpy(part->name,

Hi, > Now, I have a question: what about the "offset" parameter? How it > modifies our assumptions and calculations if the "offset" parameter is > not zero? The offset influences only the start address of the partition. The alignment goal is about the end address. So these concepts are nearly independent. Of course, partition start must be smaller than partition

> Hi, > > > Not being compatible with EFI/GPT is already a problem for the Perl > > variant. > > The relation of both is: > > isohybrid.in/.pl is being left behind. > http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/utils/Makefile > has: > SCRIPT_TARGETS += isohybrid.pl # about to be obsoleted > > isohybrid.c replaces it feature-wise

Hi, my proposal is based on a mathematical proof (see mail before) and yours is correct too. They cannot but match. Let's inspect your examples: Ady wrote: > ISO size: 1'085'736'960 bytes ( > 1GiB) This are exactly 132 cylinders of 255x63. 132 is divisible by 4. So there is no padding needed. > Cylinders (1st attempt)=132 > [...] > 2120580 / 4 = 530145, so

Hi, Ady: > > > http://www.syslinux.org/archives/2014-June/022259.html me: > > Already reported in may and diagnosed by hpa: > > http://www.syslinux.org/archives/2014-May/022041.html: > > > The right thing to do is compile it with #define _FILE_OFFSET_BITS 64 > > > and change fseek to fseeko with the appropriate type being off_t. Ady: > This has been

No #if. On May 12, 2014 6:26:18 PM PDT, Kang Kai <Kai.Kang at windriver.com> wrote: >On 2014?05?12? 22:38, H. Peter Anvin wrote: >> That is because it needs to use fseeko() and use off_t. > >Do you mean it does need a patch for isohybrid.c. And the patch looks >like: > >#if _FILE_OFFSET_BITS == 64 > fseeko(...) >#else > fseek(...) > >

That is because it needs to use fseeko() and use off_t. On May 11, 2014 11:53:17 PM PDT, Kang Kai <Kai.Kang at windriver.com> wrote: >On 2014?05?12? 10:49, H. Peter Anvin wrote: >> On 05/11/2014 06:56 PM, Kai Kang wrote: >>> When call isohybrid with option '-u', it overflows on a 32 bits >host. It >>> seeks to 512 bytes before the end of the image to

That is with syslinux 4.05 on Slackware-14.0: bash-4.2# isohybrid -v /tmp/slint64-13.3720131030-dvd.iso catalogue offset: 561 ve[0]: 1, cs: 1 ve[1]: 0, cs: 1 ve[2]: 0, cs: 1 ve[3]: 0, cs: 1 ve[4]: 0, cs: 1 ve[5]: 0, cs: 1 ve[6]: 0, cs: 1 ve[7]: 0, cs: 1 ve[8]: 0, cs: 1 ve[9]: 0, cs: 1 ve[10]: 0, cs: 1 ve[11]: 0, cs: 1 ve[12]: 0, cs: 1 ve[13]: 0, cs: 1 ve[14]: 21930, cs: 21931 ve[15]: 43605, cs:

Hi, Geert Stappers > You will see the recent commits, including the 'fseek' to 'fseeko' change. I was looking at http://git.kernel.org/cgit/boot/syslinux/syslinux.git which is what Google brings up on "syslinux git" and looks quite official. Now i wonder about +#define _FILE_OFFSET_BITS 64 after it was already done in Makefile some time earlier. Luckily,

> When call isohybrid with option '-u', it overflows on a 32 bits host. It > seeks to 512 bytes before the end of the image to install gpt header. If > the size of image is larger than LONG_MAX, it overflows fseek() and > cause error: > > isohybrid: image-x86-64-20140505110100.iso: seek error - 8: Invalid argument > > Replace fseek with fseeko to fix this issue.