[syslinux] Isohybrid wiki page and UEFI

[Ady]

> Hello,
> 
> Ady via Syslinux said on Mon, Apr 06, 2015 at 09:57:02PM +0300:
> >Can 'syslinux.efi' v.6.03 boot some media formatted with ISO9660?
> > Not at this time, no.
> 
> It took me quite some time to find that :-( Google didn't really help.
> 
> I'd like to get a bit more details on this issue:
> 
> 1/ Using syslinux.efi for PXE booting of a UEFI server is working for
>    me.
> 2/ Using syslinux.efi for booting from the local HDD of a UEFI server is
>    working for me.
> 
> 3/ Using syslinux.efi in a FAT32 image (similar to the previous 2
>    confs) stored on a iso9660 media by genisoimage and its
>    -eltorito-alt-boot -efi-boot $imagefile -no-emul-boot option doesn't
>    work. I get a red screen with debug info (attached). However, I'm not
>    trying to access anything outside of the FAT32 FS. I thought it
>    wouldn't be related to iso9660 in that use case. (I use wirtual media
>    method mounted via iLO URL CD feature if that matters)
> 
> So my question is (and sorry I started last week on that issue, read
> lots of wiki page without finding an answer, but I may have missed it
> and welcome links):
> 
> is there a way, using syslinux.efi to embed it on an ISO iso9660
> formatted image in its boot part and have a successful boot of my
> machine ? 
> I read that iso9660 support could be added to syslinux.efi for that, but
> I really have no clue where to start from, and even before trying what
> may be way outside of my capabilities, I'd alredy like to know if that
> what is really needed.
> 
> Context: I do that in order to add UEFI support to the MondoRescue
> Disaster Recovery project I'm leading (http://www.mondorescue.org). I
> used grub 0.99 for the RHEL6 support, but don't want to mess with that
> especially as I already have procedures to generate
> syslinux/isolinux/pxelinux conf files in the tool.
> 
> Thanks in advance for any hint
> Bruno.
> -- 
> Open Source Profession, Linux Community Lead WW  http://opensource.hp.com
> HP EMEA EG Open Source Technology Strategist         http://hpintelco.net
> FLOSS projects:     http://mondorescue.org     http://project-builder.org 
> Musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
> 

I apologize in advance for the length of this email. I hope someone 
would care enough to actually read it.

There are several issues to consider. 

The first one, not directly related to any bootloader in particular, is 
that the real "genisoimage" is not really up to the task for 
UEFI-booting. You either need "mkisofs" (from "cdrtools", and even 
better would be to use the latest version available, v.3.01 at the 
moment), or xorriso (which has a _slightly_ different approach in 
certain regards when comparing to mkisofs, such as the "isohybrid" 
matters, or the command line syntax / parameters related to 
UEFI-booting).

Now, regarding the file system. Using a FAT fs is commonly known to be 
supported by current UEFI firmware. As first thought, having the 
"adequate" 'syslinux.efi' file and the corresponding core module, 
"ldlinux.e*", in a FAT fs would _seem_ enough.

During "the old days", optical media would boot using a FAT image 
(using SYSLINUX or some other storage bootloader using "EL Torito 
emulation", not ISOLINUX). Then an OS-specific "driver" would allow 
access to the rest of the optical media (the ISO9660 file system); 
emphasize on "OS-specific", meaning that such access was achieved 
_after_ the OS was up and running. There were/are other methods 
available, but let's focus on this one for a moment. The firmware 
("BIOS" at the time) still had to be able to recognize the available 
optical media as potential boot device, and the correct booting steps 
had to be executed. If, for instance, the boot sector of the FAT 
(usually, floppy) image was not adequate, the booting steps would had 
eventually failed, just as with any real storage media.

UEFI firmware does not use the FAT boot sector(s). UEFI says, roughly, 
"hey, here is a file system volume that I recognize, I can understand / 
read (at least certain types of) files in this volume; let's see if I 
can find a certain kind of file that I like and then pass the control 
to it".

Let's assume you use an adequate tool (not "genisoimage") with adequate 
command line parameters so to build an adequate UEFI-bootable ISO image 
and that you correctly burn such image to optical media (or, with the 
ISO image you boot a UEFI VM as virtual optical media). Let's also 
assume that you boot in UEFI mode, and that both "syslinux.efi" and the 
corresponding "ldlinux.e*" core module load. This latter assumption is 
not trivial, as the FAT fs is not "real", but an image located on 
another (ISO9660) volume. Would 'syslinux.efi' be able to do whatever 
(and everything) it needs to do under these conditions? Could any 
kernel be _completely and successfully_ booted under these conditions?

Rhetorical question: And then what? Syslinux would have access to the 
FAT volume (usually less than 32MiB), but it would not be able to 
access the whole ISO9660 file system (or, in other words, the rest of 
the optical media, outside the FAT image). Remember, as of version 
6.03, Syslinux has no access to other file system volumes other than 
the one it booted from.

Alternatively, instead of using a "floppy-like" ("super-floppy", 
"partition-less") FAT image, you "could" try a "HDD-like" image, with 
GPT (somewhat equivalent to the "El Torito HDD-emulation" method under 
BIOS). I'm not sure it would work in real UEFI hardware, and, more 
importantly... Would anyone expect a UEFI-based hardware to boot from 
an optical device in which the booting optical media is almost-all a 
FAT32 HDD image? IMO, it would make more sense to just distribute a 
(compressed) FAT image directly (no need for ISO9660) and use other 
booting methods, such as a USB (flash) drive (which 'syslinux.efi' can 
boot from).

There are methods to develop file system "UEFI applications", a way to 
add support to additional specific file systems. If a UEFI firmware 
understands FAT (as it is known to happen in current UEFI-based 
hardware), and/or if there was some way to add support for ISO9660 (at 
each booting occasion), and if "syslinux.efi" would understand ISO9660 
(in a similar way as files can be read after booting with ISOLINUX 
under BIOS, generally speaking), and if the Syslinux family of boot 
loaders would be able to have access to other volumes (other than the 
one it booted from), _then_ we might probably be able to use 
"syslinux.efi" to boot optical media in a _meaningful manner_. We are 
far from such conditions, as of Syslinux 6.03.

BTW, "multifs" is on its way (at some point in the future), but, 
strictly 
speaking there is not real "planning", and certainly no ETA. Please 
avoid going 
off-topic.

Regards,
Ady.