similar to: Chainload El Torito grub2 from syslinux from a partition table

Hi, H. Peter Anvin: > It means that the .iso can be booted from a partition using any of the > standard MBRs (not necessarily altmbr), But the --partok MBRs (isohdpp*) stem from altmbr ? If so: don't they need the partition number patched in ? (If not: i have to rethink the link to article "Mbr" at http://www.syslinux.org/wiki/index.php/Isohybrid#MBR_selection ) >

Thomas Schmitt wrote: > I have some problems understanding the details of the program's flow. > > - The code inside PARTITION_SUPPORT is supposed to be inactive with > MBR isohdpfx.bin. It belongs to isohybrid --partok which is equivalent > to MBRs isohdppx*.bin. Debian uses isohdpfx.bin. Yes. isohdpfx.bin is generated from isohdpfx.S in which PARTITION_SUPPORT is not

Hi, i am trying to document the MBR selection by isohybrid option --partok. I assume it is related to "altmbr.bin" as described in http://www.syslinux.org/wiki/index.php/Mbr But there i read "altmbr.bin [...] boots from a partition with fixed number, see below." The "see below" probably refers to "The altmbr.bin (all 3 variants) is only 439 bytes long, -- one

Hi, I'm trying to boot Debian-Installer image from extlinux with chain.c32; i.e.: - I'm doing this from a loopback device (loop0) which later will be dumped to an USB stick. - GPT disklabel. - Partition 15 (loop0p15) contains extlinux info, and partition 12 contains Debian multi-arch installer image *dumped*[1], and its corresponding menu entry for extlinux is something like: LABEL

----- Original Message Follows ----- From: kasra kangavari <kasra_kng@yahoo.com> To: fulvio.ricciardi@zeroshell.net Subject: Re: [Bridge] Passing vlan tagged packets through linux bridge(2.6.19) Date: Sat, 2 Dec 2006 00:16:12 -0800 (PST) > Dear Fulvio > > I wanna know if your linux box ethernets are 1000 or 100 > ? > and are you sure about kernels < 2.6.15 that large

On 06/25/2014 01:16 AM, Thomas Schmitt wrote: > Hi, > > i am trying to document the MBR selection by isohybrid option --partok. > > I assume it is related to "altmbr.bin" as described in > http://www.syslinux.org/wiki/index.php/Mbr > But there i read > "altmbr.bin [...] boots from a partition with fixed number, see below." > > The "see

Thomas Schmitt wrote: > Since we know that the isolinux.bin binary is well ok on other partitions, > i'd say that the MBR code does not load the right blocks from disk when > it wants to get isolinux.bin. Yes, these are my thoughts as well. I think the jump from GRUB to the isohybrid code on the logical partition is working fine, but when the isohybrid code is trying to jump to

Hello all, The question is not necessarily CentOS-specific - but there are lots of bright people on here, and - quite possibly - the final implementation will be on CentOS hence I figured I'd ask it here. Here is the situation. I need to configure a Linux-based network load balancer (NLB) solution. The idea is this. Let us say I have a public facing load balancer machine with an public IP

Thomas Schmitt wrote: > So if we had a MBR which prints the content of the first 512 read bytes > we could tell whether they are block aligned and from which block they > come. Ok. I'll try. Is it the isohdppx or isohdpfx (or both) that is relevant? Meanwhile I have a hacked isohdppx.bin that prints: G if GPT M if MBR <nothing> if no partition info E if EBIOS C if not EBIOS

I've attempted to understand what the isohybrid tool is doing, specifically with the "--partok" flag. As far as I can see, this essentially trims off the first 3 bytes of the custom isohybrid MBR image before applying it to the ISO. Can anyone explain how this enables the ISO to "be happy" on a partition, rather than whole disk? And does anyone have suggestions for what

Thanks for the clarification Thomas. Thomas Schmitt wrote: > (Did you already tell which partitions exist and in which one do you want > to put your ISO ?) I've tried a number of different structures, but the results are consistent (boots fine from primary partitions, not from logical partitions). For example for a disk partitioned like below: Disk /dev/sdc: 3.8 GiB, 4007657472

Hi, Duncan Elliot wrote: > What is the thought process of clearing the ISO MBR? It is not necessary in the partok case, because the partition to which you copy the image encloses the ISO, exposes it for mounting, and protects it from partition editors. (Another idea from assembler riddling turned out to be a red herring.) Without understanding the language or the BIOS habits of MBR

Hi, Duncan Elliot wrote: > As far as I can see, this essentially trims off the first 3 bytes of the > custom isohybrid MBR image before applying it to the ISO. You probably mean this line: memcpy(mbr, &isohdpfx[hd0 + 3 * partok], MBRSIZE); The indize do not apply to bytes but to byte arrays of size MBRSIZE. extern unsigned char isohdpfx[][MBRSIZE]; (hd0 + 3 * partok)

From: MartinS <ams at ludd.ltu.se> isohdp[fp]v.S which says E or C if EBIOS or CBIOS is used. isohdppv.S also says G or M if a GPT or MBR partition is detected. Signed-off-by: MartinS <ams at ludd.ltu.se> --- Comments? diff --git a/mbr/Makefile b/mbr/Makefile index be2bded..7095396 100644 --- a/mbr/Makefile +++ b/mbr/Makefile @@ -21,7 +21,8 @@ include $(MAKEDIR)/embedded.mk all:

Hi, I have been attempting to set up a multi-boot USB stick (i.e. multiple bootable ISO images on the one stick) I have had good success by: - processing ISO with isohybrid (with "partok" flag) - dd'ing ISO to primary partitions on the USB stick (e.g /dev/sdc2, /dev/sdc3, /dev/sdc4) - installing grub to USB stick and configuring to chainload to these partitions To remove the limit

I thought I've found three bugs on syslinux 6.03: (1) With sample config file as is, i.e. leaving commented MENU VSHIFT and MENU COLOR UNSEL but uncommented MENU COLOR SEL: A black "border" is displayed below the selected line and on its right edge. (2) Uncommenting MENU COLOR UNSEL: This effect appears also on separators and on right edge on every unselected lines. (3)

Ferenc Wagner <wferi at niif.hu> writes: > The internal Gnu-EFI build gives me grief: [...] Previous points still standing, but now I tried cleaning out everything by hand. I don't know whether it matters, but building gnu-efi pollutes its source directory (unlike syslinux itself) with the following files at least (found by git status in the gnu-efi submodule):

Hi, Ady wrote: > We seem to be suggesting to just dd' the first 432 bytes of their USB > devices with Martin's isohybrid Yes. As long as it is not about the old Macs which the APM of Fedora and some Gentoo ISOs wants to make boot, and not about ISOs made with isohybrid options --partok -ctrlhd0 --forcehd0. > which would be the step-by-step instructions for users of other >

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

Hi, Martin Str|mberg wrote: > And given that space in isohdpfx is very limited (432 bytes) perhaps > the right thing might be to not have that xor in there. > But then better safe than sorry, and given that there is space _now_, > why not? I still agree. But while answering Ady's questions i get to a question of my own: Do all six fixed isohdp*.bin variations still fit into 432