Syslinux - Jul 2018 - help booting iso's?

Hi. I prefer using the syslinux boot loader and recently undertook a 
project of creating a multiboot USB drive that boots using syslinux. The 
aim is to create a medium from which various live linux environments can 
be run for things like system maintenance, installation, and perhaps 
demonstration. I anticipate using this multiboot USB drive on mostly 
legacy, BIOS systems, if that matters.

As many syslinux users would likely anticipate, some iso image files I've 
tested boot just fine using memdisk. For some other iso's, I found some 
directives on the web that advise loop-mounting the iso's, copying over to 
the multiboot USB certain files and folders, and crafting applicable 
syslinux.cfg stanzas. I've managed get a few more live environments 
booting already via those methods. But, since not all live-environment 
iso's are constructed in the same way, not all are readily susceptible to 
the same sorts of directives. One case in point is the Void Linux iso.

I'd first like to ask about something that was suggested as a possible 
solution but about which I could find no documentation. I was led to 
believe that it would be possible, using syslinux, to boot an iso image 
located within a partition by somehow specifying its address on disk. I 
see nothing in syslinux documentation, guidelines, or forum postings, that 
suggests that this is really possible. So, am I correct in assuming that 
the individual who suggested that is just plain wrong?

In order to succeed in booting into the the Void live environment the iso 
provides, what I wound up doing is creating some appropriately-sized 
partitions on my USB drive and dd'ing the iso image to one of them (I 
created an extended partition and included within it 6 logical 
partitions). I'd understood that syslinux would be capable of booting such 
a partition, and there even seem to be official directives on doing that 
sort of thing. But nothing I have tried so far will allow me, using 
syslinux, to boot the iso dd'd to that partition--regardless of whether I 
specify in the syslinux.cfg entry the address of the iso's mbr, or the 
partition's location (e.g., hd0, 5).

One point of confusion I have is how to specify the drive that syslinux is 
booted from, and thus the one on which the dd'd partition is located: it 
being a USB drive rather than the computer's hard drive, perhaps hd0 is 
not the correct specifier? Can anyone offer clarification on that issue?

Incidentally, I recently put grub4dos on this USB drive, since I'd 
understood it was more capable when it comes to booting iso's. Since it 
was already present, I decided, using a syslinux menu item that would 
invoke grub4dos, to try booting the partition with it. And, with an 
appropriate menu.lst item, the partition does, in fact, boot this way. The 
relevant entry is:

title Boot Void 64-bit dd'd to 1st logical partition
map --heads=0 --sectors-per-track=0 (hd0,4)0+716800 (0xff)
map --hook
chainloader (0xff)

Any assistance in getting such partitions to boot using syslinux will be 
much appreciated. Thanks.

PS Various syslinux.cfg entries I've tested in my attempts to boot the 
partition straight from the syslinux menu:

LABEL Void linux 64
MENU LABEL Void Linux x86_64
COM32 chain.c32
APPEND mbr:0x2addfccb

LABEL Void linux 64
MENU LABEL Void Linux x86_64
COM32 chain.c32
APPEND hd0 5

LABEL Void linux 64
MENU LABEL Void Linux x86_64
COM32 chain.c32 mbr=0x2addfccb

LABEL Void linux 64
MENU LABEL Void Linux x86_64
COM32 chain.c32 hd0, 5

LABEL Void linux 64
MENU LABEL Void Linux x86_64
COM32 chain.c32
APPEND hd1 5
# being unsure whether I'd specified correctly the USB drive as hd0

You'll pull your hair out trying to get this going due to either lack of
documentation, and or due to Void Linux maintainers not doing it the 'right
way'. I've been there and found that many, many Linux distros do not
boot
properly out-of-the-box using memdisk. I came to the conclusion that if
it's not KISS and/or standardized I'll drop it.

An alternative instead of booting from USB Flash drives (which can be
tricky on very old PCs and also is a pain to maintain and test) is (i)PXE
booting using https://netboot.xyz/ btw. This is where I moved to and I
haven't looked back.

On Fri, Jul 6, 2018 at 3:08 PM, James Miller via Syslinux <
syslinux at zytor.com> wrote:
> Hi. I prefer using the syslinux boot loader and recently undertook a
> project of creating a multiboot USB drive that boots using syslinux. The
> aim is to create a medium from which various live linux environments can be
> run for things like system maintenance, installation, and perhaps
> demonstration. I anticipate using this multiboot USB drive on mostly
> legacy, BIOS systems, if that matters.
>
> As many syslinux users would likely anticipate, some iso image files
I've
> tested boot just fine using memdisk. For some other iso's, I found some
> directives on the web that advise loop-mounting the iso's, copying over
to
> the multiboot USB certain files and folders, and crafting applicable
> syslinux.cfg stanzas. I've managed get a few more live environments
booting
> already via those methods. But, since not all live-environment iso's
are
> constructed in the same way, not all are readily susceptible to the same
> sorts of directives. One case in point is the Void Linux iso.
>
> I'd first like to ask about something that was suggested as a possible
> solution but about which I could find no documentation. I was led to
> believe that it would be possible, using syslinux, to boot an iso image
> located within a partition by somehow specifying its address on disk. I see
> nothing in syslinux documentation, guidelines, or forum postings, that
> suggests that this is really possible. So, am I correct in assuming that
> the individual who suggested that is just plain wrong?
>
> In order to succeed in booting into the the Void live environment the iso
> provides, what I wound up doing is creating some appropriately-sized
> partitions on my USB drive and dd'ing the iso image to one of them (I
> created an extended partition and included within it 6 logical partitions).
> I'd understood that syslinux would be capable of booting such a
partition,
> and there even seem to be official directives on doing that sort of thing.
> But nothing I have tried so far will allow me, using syslinux, to boot the
> iso dd'd to that partition--regardless of whether I specify in the
> syslinux.cfg entry the address of the iso's mbr, or the partition's
> location (e.g., hd0, 5).
>
> One point of confusion I have is how to specify the drive that syslinux is
> booted from, and thus the one on which the dd'd partition is located:
it
> being a USB drive rather than the computer's hard drive, perhaps hd0 is
not
> the correct specifier? Can anyone offer clarification on that issue?
>
> Incidentally, I recently put grub4dos on this USB drive, since I'd
> understood it was more capable when it comes to booting iso's. Since it
was
> already present, I decided, using a syslinux menu item that would invoke
> grub4dos, to try booting the partition with it. And, with an appropriate
> menu.lst item, the partition does, in fact, boot this way. The relevant
> entry is:
>
> title Boot Void 64-bit dd'd to 1st logical partition
> map --heads=0 --sectors-per-track=0 (hd0,4)0+716800 (0xff)
> map --hook
> chainloader (0xff)
>
> Any assistance in getting such partitions to boot using syslinux will be
> much appreciated. Thanks.
>
> PS Various syslinux.cfg entries I've tested in my attempts to boot the
> partition straight from the syslinux menu:
>
> LABEL Void linux 64
> MENU LABEL Void Linux x86_64
> COM32 chain.c32
> APPEND mbr:0x2addfccb
>
> LABEL Void linux 64
> MENU LABEL Void Linux x86_64
> COM32 chain.c32
> APPEND hd0 5
>
> LABEL Void linux 64
> MENU LABEL Void Linux x86_64
> COM32 chain.c32 mbr=0x2addfccb
>
> LABEL Void linux 64
> MENU LABEL Void Linux x86_64
> COM32 chain.c32 hd0, 5
>
> LABEL Void linux 64
> MENU LABEL Void Linux x86_64
> COM32 chain.c32
> APPEND hd1 5
> # being unsure whether I'd specified correctly the USB drive as hd0
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>


-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign <http://comicsanscriminal.com>

> Hi. I prefer using the syslinux boot loader and recently undertook a 
> project of creating a multiboot USB drive that boots using syslinux. The 
> aim is to create a medium from which various live linux environments can 
> be run for things like system maintenance, installation, and perhaps 
> demonstration. I anticipate using this multiboot USB drive on mostly 
> legacy, BIOS systems, if that matters.
> 
> As many syslinux users would likely anticipate, some iso image files
I've
> tested boot just fine using memdisk. For some other iso's, I found some
> directives on the web that advise loop-mounting the iso's, copying over
to
> the multiboot USB certain files and folders, and crafting applicable 
> syslinux.cfg stanzas. I've managed get a few more live environments 
> booting already via those methods. But, since not all live-environment 
> iso's are constructed in the same way, not all are readily susceptible
to
> the same sorts of directives. One case in point is the Void Linux iso.
> 
> I'd first like to ask about something that was suggested as a possible 
> solution but about which I could find no documentation. I was led to 
> believe that it would be possible, using syslinux, to boot an iso image 
> located within a partition by somehow specifying its address on disk. I 
> see nothing in syslinux documentation, guidelines, or forum postings, that 
> suggests that this is really possible. So, am I correct in assuming that 
> the individual who suggested that is just plain wrong?
 
 
Although I'm not "absolutely/%100/completely" discarding that
under
very specific circumstances such method could, perhaps, be possible, I 
would say that you should forget about such suggestion. The alternative 
to these words would be: the person who insinuated such method as 
plausible should be much more specific and provide (step-by-step) 
details (explicitly stating that (s)he already performed such steps 
with successful results).

> 
> In order to succeed in booting into the the Void live environment the iso 
> provides, what I wound up doing is creating some appropriately-sized 
> partitions on my USB drive and dd'ing the iso image to one of them (I 
> created an extended partition and included within it 6 logical 
> partitions). I'd understood that syslinux would be capable of booting
such
> a partition, and there even seem to be official directives on doing that 
> sort of thing. But nothing I have tried so far will allow me, using 
> syslinux, to boot the iso dd'd to that partition--regardless of whether
I
> specify in the syslinux.cfg entry the address of the iso's mbr, or the 
> partition's location (e.g., hd0, 5).
> 
> One point of confusion I have is how to specify the drive that syslinux is 
> booted from, and thus the one on which the dd'd partition is located:
it
> being a USB drive rather than the computer's hard drive, perhaps hd0 is
> not the correct specifier? Can anyone offer clarification on that issue?
 
 
There are at least 2 pages in the official Syslinux wiki with 
information about "chain.c32" and the way the booting device is 
expected to be identified by it.

At any rate, I very much doubt that the problem is the way each 
partition should be referenced in syslinux.cfg.

> 
> Incidentally, I recently put grub4dos on this USB drive, since I'd 
> understood it was more capable when it comes to booting iso's. Since it
> was already present, I decided, using a syslinux menu item that would 
> invoke grub4dos, to try booting the partition with it. And, with an 
> appropriate menu.lst item, the partition does, in fact, boot this way. The 
> relevant entry is:
> 
> title Boot Void 64-bit dd'd to 1st logical partition
> map --heads=0 --sectors-per-track=0 (hd0,4)0+716800 (0xff)
> map --hook
> chainloader (0xff)
> 
> Any assistance in getting such partitions to boot using syslinux will be 
> much appreciated. Thanks.
> 
> PS Various syslinux.cfg entries I've tested in my attempts to boot the 
> partition straight from the syslinux menu:
> 
> LABEL Void linux 64
> MENU LABEL Void Linux x86_64
> COM32 chain.c32
> APPEND mbr:0x2addfccb
> 
> LABEL Void linux 64
> MENU LABEL Void Linux x86_64
> COM32 chain.c32
> APPEND hd0 5
> 
> LABEL Void linux 64
> MENU LABEL Void Linux x86_64
> COM32 chain.c32 mbr=0x2addfccb
> 
> LABEL Void linux 64
> MENU LABEL Void Linux x86_64
> COM32 chain.c32 hd0, 5
> 
> LABEL Void linux 64
> MENU LABEL Void Linux x86_64
> COM32 chain.c32
> APPEND hd1 5
> # being unsure whether I'd specified correctly the USB drive as hd0
 
 
Several side-notes:

_ The LABEL directive should not use spaces (i.e. don't use space 
characters in "Void linux 64").

_ Each LABEL should be unique (i.e. don't repeat labels)

_ Using chain.c32, you seem to be trying to chainload an ISO9660 
filesystem. I very much doubt that this will work.

_ Some users seem to think that every-and-all ISO images can be loaded 
by means of MEMDISK and somehow expect for every-and-all of them to 
successfully boot. Some of these users also seem to think that this is 
the simpler method to "multiboot". Both assumptions are, generally 
speaking, inaccurate (to say the least).

_ Whether using MEMDISK or grub4dos, booting "whole ISO images" 
requires a "lot of RAM".

_ Many ISO images are ISOHybrid. I know of _no_ ISOHybrid image for 
GNU/Linux distribution that is distributed ready-to-burn on partition 
devices - in theory, they could, but they don't, and that makes sense. 
They are built to be "ready-to-burn" to _whole_ devices, not to 
partitions. They are also not built to be "multibooted".

_ If interested, I could mention several projects that already make the 
matter of "multibooting" (from USB devices) easier for _common users_ 
(without "demanding" from _common users_ to learn even more technical 
details, nor having to learn even more alternative methods of booting, 
such as ipxe).

Regards,
Ady.