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

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:

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

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. Signed-off-by: Kai Kang <kai.kang at

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

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

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

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,

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,

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

> 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, > 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, > > > 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): >

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: wrlinux-image-x86-64-20140505110100.iso: seek error - 8: Invalid argument >

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:

I'll file a ticket once fedorahosted is back online. The request is to port the isohybrid script, in the syslinux package, from perl to C (and of course submit it upstream). This would let syslinux drop its dependency on perl, which would save considerable space. $ wc -l git/syslinux/utils/isohybrid.in 258 git/syslinux/utils/isohybrid.in As this is doing some simple structure unpacking

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,

I have just pushed out Syslinux 3.81-pre10. This fixes some pretty serious bugs, including the fact that, apparently, isohybrid didn't work at all in CBIOS mode. Unfortunately it means that the isohybrid handover protocol has changed, and so a new isolinux.bin isn't compatible with an old isohybrid or vice versa (as a result, the magic number has changed.) -hpa

Good day, Matthew. I recently got stuck while building Syslinux as <uuid/uuid.h> doesn't exist on my system. The #inclusion was introduced in commit 2c3a24e5f4b807ec31595227afa59a818c060ca9. Whence does this file come, if you please? I'm assuming it is the Linux kernel's, but can't seem to understand the directory prefix, in that case. - Shao