similar to: Announcing a patch series for isohybrid.c

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

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 worst sin of isohybrid.c was to compose GPT partition names by 8-bit characters and to memcpy() them as if they were 16 bit wide. GPT names are encoded as UTF-16LE. It is trivial to create this encoding from 7-bit ASCII. This change introduces two byte arrays with the desired UTF-16LE names which replace the string constants "ISOHybrid ISO" and "ISOHybrid". ---

Op 2014-06-23 om 20:09 schreef syslinux-bot for H. Peter Anvin: > Commit-ID: f9dad5340bcefe34d860e991e8743be01a4d6c3c > Gitweb: http://www.syslinux.org/commit/f9dad5340bcefe34d860e991e8743be01a4d6c3c > Author: H. Peter Anvin <hpa at zytor.com> > AuthorDate: Mon, 23 Jun 2014 20:06:51 -0700 > Committer: H. Peter Anvin <hpa at zytor.com> > CommitDate: Mon, 23

> > Same result as yours. > > > Have a nice day :) > > Thomas > I was under the impression (apparently the wrong one) that your pseudo-code was adding 4 cylinders to the first example, from 132 to 136, which would be non-optimal. Since I am not a developer, I believe you when you say that such jump won't happen :). Perhaps the code will be more clear to me

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

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

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

The GPT partition 1 covers the whole ISO filesystem size. GPT specs demand that the partition end block number shall be the last valid block in the partition. isohybrid.c rather wrote the number of the first block after the partition end. This change reduces the number by 1. --- utils/isohybrid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/utils/isohybrid.c

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,

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.

Dear list, I have been trying to debug a build failure for a while in the utils directory on isohybrid which seems to be distro specific. On Fedora 17 64bit the build completes without problems, but under both Ubuntu 32/64bit 11.10 and 12.04 I get the following: tim at oxygen:/usr/src/git/syslinux/utils$ make gcc -O2 -luuid -o isohybrid isohybrid.o isohdpfx.o isohybrid.o: In function

Various EFI systems insist that there be no active flag in the pMBR in order to parse the GPT. The only way around this is to also generate a valid MBR - the firmware will then pick that up and use the system partition provided there. In order to deal with other EFI "sanity" checks, the partition type for the non-EFI partitions is set to 0 to skip the firmware bailing because of

> Hi, > > > Hopefully I am explaining it better this time. > > Our ideas of implementation are supposed to yield the > same result. > Hmm, I am not sure. Or perhaps I am misunderstanding your code. Let me try with an example (or two). For this example, let's assume: -h 255 -s 63 ISO size: 1'085'736'960 bytes ( > 1GiB) This size happens to be a

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

Hi, > Hopefully I am explaining it better this time. Our ideas of implementation are supposed to yield the same result. As said, i am willing to implement my proposal in a copy of isohybrid.c, if somebody wants to test it. Advantages and disadvantages should be obvious. Interested users please send util/isohybrid.c from your local SYSLINUX source code installation to me. Just to be sure

> Hi, > > Ady wrote: > > I am not so sure that using a different pair of '-h' and '-s' values > > would be better than using 255/63. > > But 255 * 63 is not divisible by 4 and thus can cause > trouble with virtual DVD-ROM. And my suggestion to modify the _amount_ of Cylinders was intended to overcome the "by 4" (or rather, "by

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

The block counts in the APM partitions assumed 512 bytes per block, whereas the start block numbers assume 2048 as announced in the APM header. This change divides the affected block counts by 4 to correct the assumption. --- utils/isohybrid.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/utils/isohybrid.c b/utils/isohybrid.c index c5b4281..7d0864e 100644 ---

Hi, Ady wrote: > I am not so sure that using a different pair of '-h' and '-s' values > would be better than using 255/63. But 255 * 63 is not divisible by 4 and thus can cause trouble with virtual DVD-ROM. > Most BIOS and most partition editors would assume this geometry. I cannot tell for BIOSes, but partition editors have options to set heads-per-cyl and