similar to: [PATCH] isohybrid: user options

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

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

Op 2014-06-20 om 15:56 schreef Ady: > > The Perl variant, isohybrid.in, seems to be getting left behind > regarding several patches. I don't recall whether there is at least > some mention in the isohybrid docs about the existence of 2 variants > included in Syslinux (and that is in addition to other isohybrid > methods outside Syslinux). Is there any reference? >

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.

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

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

> 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

Greetings, I have a problem that is baffling me. My host machine is an older Dual Xeon machine that does not support HVM - PAE is supported. I have 2008.11 b98 installed as Dom0. I''m trying to install the same as a DomU. In the DomU, I''m starting the ssh service, logging in with X forwarding and starting the gui with: (dom1) jack$ pfexec gui-install The gui displays on my

I'm going to get the hang of this mailing list eventually. Apologies for any duplicate emails.. >Ian Bannerman: >> While I did know the .exe variant was not official / untrusted, >Is there a special reason for this ? (Except the known bugs which affect Linux binaries, too.) Not really. I had never found a convincing source for it and had seen previous list entries like this

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

Hello everyone, I am maintaining a distribution loosely based on LFS and am now trying to add UEFI support. Integrating a FAT formatted partition image containing, preloader, gummiboot, kernel and initramfs correctly results in a ISO image that is bootable on BIOS and UEFI systems if booted from the optical drive. However, when I run isohybrid --uefi name-of.iso the resulting GPT entry for

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

Hi, On 29/07/2014 23:19, Thomas Schmitt wrote: > A good opportunity to brag with xorriso's boot inspection > features (since xorriso-1.3.8): Yes! I've upgraded libburn, libisofs and libisoburn so now I can play with it too ;) > I forgot to advise (or misadvise) -isohybrid-apm-hfsplus with > the image /isolinux/efiboot.img . So we only got one APM > partition here. A

Hi, Miller, Shao: > I am enjoying this discussion Me not. I feel quite misunderstood. hpa: > Actually, I would prefer if you removed this in its current form. Ok. Will do. If any viable solution emerges, please let me know. Have a nice day :) Thomas

Hi, Didier Spaier: > I uploaded both ISO images on http://slint.fr/misc/MacBoot A good opportunity to brag with xorriso's boot inspection features (since xorriso-1.3.8): xorriso -indev slint64-14.1-Thomas_mkisofs.iso \ -report_el_torito plain \ -report_system_area plain yields (block size is 2048): El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz

Hi, On 29/07/2014 21:34, Thomas Schmitt wrote: > Nevertheless i advise Didier to simply try with 0xef rather than Mac. At least the ISO will then have MBR, GPT and APM entries for the file macboot.img. I did that, and also tried the xorriso command you posted. I uploaded both ISO images on http://slint.fr/misc/MacBoot resp. renamed: slint64-14.1-Thomas_mkisofs.iso

I posted this on the bugzilla page but I figured that on the mailing list it would get more attention. Please see http://bugzilla.syslinux.org/show_bug.cgi?id=49 for a description of my current issue. -- Thank you, Fernando Reyes GPG BDD75DD7 Mission Accomplish, Inc. http://missionaccomplish.com Email:design at missionaccomplish.com Tel: 7187100008 Cell: 3479275477

This moves the xen_modified_memory call from cpu_physical_memory_map to cpu_physical_memory_unmap because the memory could be migrated before the device model have written to it. But because we need to know the guest address and to avoid rewriting a new function, the call is moved to qemu_invalidate_entry. So this later has to new parameters, the length of the mapping and if it was a write.

I have addressed all the issues that I know about (including, hopefully, the isohybrid version dependence...). I would like to release this this week so please let me know as soon as possible if this version is "go". -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

Hi, Ady wrote: > If a specific BIOS' CHS/LBA translations cannot cope with the above, it > is no surprise that we get some mess, somewhere. Currently my suspicion is that the isohdpfx.S code simply mishandles the two conversion factors which it correctly got from BIOS call INT 13H AH 8. > Boot System ID : First : Last : Relative : Number of: > Flag