similar to: isohybrid: change default offset to 1 to avoidparted troubles

Using the default offset 0, parted will complain about a recursive partition and will be unable to do any further work on a USB device that uses an isohybrid image created with offset 0. Setting offset to 1 will fix this. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: isohybrid.in-change-offset.patch URL:

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): http://hg.slitaz.org/wok/file/313b384e2a06/syslinux/stuff/tools/isohybrid.sh But isohybrid.exe must

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 and adds new features. Only those new features contain the bugs,

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

We been trying to boot the image in vbox using efi emulation but it complains about kernel not supporting handover. Anyways, I will take your advice and get back to you tomorrow. I think we might be getting close to a successful boot on Mac OSX hardware and any other UEFI capable hardware. Thanks for your help and tomorrow I should come with more data to debug. P.S the latest fedora ISO seems

Hi, Ady: > _ Wiki should use more user-friendly language and "less deep" > technical information. I tried to stay at the surface of isohybrid. (Didier already asked for more depth about expert options.) > _ In the Syslinux wiki, "PC-BIOS" should rather be called plain > "BIOS". I understand there are other "BIOS" for other hardware. But

??? Hi, Recently it was brought to notice by Mr Steffen(snwint at suse.de) that ---- > syslinux 4 comes with a C-rewrite of isohybrid. Unfortunately the option > parsing has changed: it no longer accepts hex numbers (0x...). Was this > intentional or can we have the old behaviour back (say, changing > sscanf(%u) -> sscanf(%i))? > I've made the changes to the current git

On 01/11/2013 18:40, Didier Spaier wrote: > On 01/11/2013 05:36, Ady wrote: >> >>> 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 >>>

Hi, email at missionaccomplish.com wrote: > We been trying to boot the image in vbox using efi emulation but it > complains about kernel not supporting handover. If it complains about a kernel then it should be past El Torito or GPT. The job of xorriso is to point BIOS and EFI to their boot images. Everything else is in the scope of the boot images resp. the operating system that shall

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

Hi, Ady: > Since both included variants are currently different, and both > variants have problems I am not aware of problems of the perl version. It is just lacking the newer features which support EFI/GPT and Mac/APM. The known bugs of isohybrid.c are with those newer features. http://www.syslinux.org/archives/2012-May/017843.html

Hi, Ady wrote: > Hmm, but dd'ing isohybrid images is so simple...! > You have the freedom to waste your time. But dd-ing is the reason why isohybrid exists. Matthew Garrett extended the BIOS hard disk use case to UEFI in 2011 and 2012. hpa signed it off and committed it. See

Hi, i wrote: > > Not only MBR writing but also reading of the Primary Volume Descriptor > > and of the El Torito catalog by isohybrid.c are currently prone to > > unwanted CR-insertion. Miscalculations can be caused by this. I have to correct myself: Carriage Return characters (byte value 13 = 0x0d) are not at risk to be inserted, but rather to be removed if they happen to be

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, > For instance, if a common user reads a section about a general > concept, then introducing commands of specific tools (even with the > intention of clarity) could make the reader (mis)understand that such > tool or such commands are part of the general concept. The first example with "xorriso ... -isohybrid-mbr" serves the purpose to explain how the isohybrid

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, > Unfortunately I get the error message: > isohybrid: slint64-14.1.iso: unable to find mac efi image This is probably due to El Torito Platform id "Mac" in -eltorito-alt-boot -no-emul-boot -eltorito-platform Mac \ -eltorito-boot isolinux/macboot.img \ This caused in the image http://slint.fr/misc/MacBoot/slint64-14.1.iso platform id 1 with the third image. (I would

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

Hi, Ady wrote: > This could be misinterpreted by some users as: "if > you want to build an isohybrid image, then you cannot use > 'syslinux.efi'". This would be incorrect. I don't know whether syslinux.efi can be used for booting from ISO 9660 via UEFI. Currently there is no example around which would succeed without GRUB or GRUB2. When describing the UEFI

> Hi, > > at [Tails] we're in the process of shipping hybrid ISO images by > default again. We're using `isohybrid -h 255 -s 63' to do that (thanks > to the advice we got on this mailing-list a few months ago!). > > And then, we've discovered that sometimes, isohybrid produces ISO > images whose size is not a multiple of 2048 bytes. > > Who cares?