[syslinux] Isohybrid wiki page and UEFI

[Ady]

> Hi,
> 
> some minor nitpicking on Ady's summary:
> 
> > the real "genisoimage" is not really up to the task for 
> > UEFI-booting.
> 
> In some distros, genisoimage offers option -e for embedding
> a FAT filesystem image.
> (genisoimage is a fork of mkisofs, so "real" is somewhat
>  misleading in respect to history.)
> 
> For details see:
>   http://www.syslinux.org/wiki/index.php/Isohybrid#UEFI
 
OK, if the term "real" in the context of that sentence could 
potentially cause some misunderstanding, then let me clarify what I 
meant. In the "Linux world", there are currently 3 "popular" 
command-line tools for these matters:

_ "xorriso";
_ "mkisofs", part of "cdrtools" (currently at version 3.01);
_ other "thingies" with several forks, patches, iterations, 
customizations...

Some Linux distros use some kind of "redirection" or "renaming", so 
when a user writes 'genisoimage' with some additional command-line 
parameters, the actual tool that executes the command might be some 
other "thingie" (with some patch, or a fork, or whatever). The actual 
package might even be "mkisofs", but the user writes the command as 
'genisoimage'. It all depends on the redirection / renaming / 
sym-linking / script in each distro.

So, someone could ask about the reason(s) I suggested not to use 
"genisoimage". Well, xorriso and cdrtools (mkisofs) are both currently 
maintained and both support UEFI-related parameters, but the other 
"thingies" (with they countless customizations, patches, special cases 
and whatnot) are not really up-to-date, and in some distros they are 
not maintained (at all).
 
> 
> I am author of xorriso and willing to help with ISO 9660
> composition, if questions arise.
> 
> 
> > 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 am not aware that EFI interprets the possibly present partition
> table of the FAT image in the EFI System Partition.
> (Regardless whether found by MBR partition table entry, GPT entry,
>  or El Torito boot catalog entry.)
> 
> EFI from CD/DVD/BD has a soft size limit of 32 MB for its
> System Partition.
> That's due to the format of El Torito Boot Catalog which
> counts the 512-bytes blocks by a 16-bit unsigned integer.
> 
> But one may attribute size 0 or 1, which means that the System
> Partition reaches up to the end of the medium. (UEFI 2.4, 12.3.2.1)
> There is no harm if actually other data are stored after the FAT
> image.
 
Since the topic was about "syslinux.efi", I didn't want to get into 
those technical details. Although I am not a developer, I was already 
aware of these potential options you are mentioning. Here is the first 
catch: real-life firmware (whether BIOS or UEFI, but especially the 
latter at this point in time) do not always behave as it is expected 
(by users, or by the standards / specifications, or by none of them). 
In some (few) occasions, they behave "better" (from the point of view 
of common users) than the specs pretended, but, 
more-frequently-than-we-would-like, real-life firmware fails to comply 
with standards / specs.

Whether it is not contemplated in the specs, or because real-life 
firmware is usually developed and maintained according to some specific 
bootloader's behavior, my statement is valid: "I'm not sure it would 
work in real UEFI hardware".

> 
> This feature was still on my todo list. I took the occasion to
> implement it in xorriso.
 
And here is the second catch: tools that are actually able to do the 
thing, and users that would know how exactly to achieve it (and then, 
how to take advantage of the result). Someone could even think about 
this one as a "catch-22" case. In any case, the continuous development 
of xorriso is a good thing; thank you.
 
> Now looking for testers with a real use case.
> 
> 
> > 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?
> 
> In principle this should work.
 
And real-life UEFI implementations "should" be updated for Linux users 
too, with support for bootloaders that follow (open) standards, not 
just according to the most popular one. Well, this "should" is a 
wishful thinking, not real life.
 
> But i saw rumors that attempts with SYSLINUX were not successful.
> (Hard to say why failure happens with so many parameters involved.)
 
Indeed, too much confusion, mixing UEFI specs with what some specific 
bootloader's behavior with some particular ways to do things, with 
crappy firmware, with 1600+ pages of "specs", with users' 
misunderstandings...
 
> 
> With BIOS, a similar method is used by a Seagate firmware installer
> ISO image. Most of its software is in an El Torito floppy image
> with a DR-DOS operating system on it. The ISO 9660 filesytem tree
> is nearly empty.
> So this ISO boots from CD into DR-DOS and (nearly ?) all further
> processing stays in there. ISO 9660 is mainly used to make the
> El Torito catalog visible to BIOS.
> 
> 
> >  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
> 
> This should be a viable method indeed, if not booting from optical
> media is desired.
> 
> 
> The Linux distros rather use a tiny GRUB2 FAT image with embedded
> configuration (without any dialog of course) from where GRUB2
> starts a search for the filesystem with the larger GRUB2
> installation which finally offers a user visible menu.
> 
> 
> Have a nice day :)
> 
> Thomas
 
 
I still would like more details from Bruno. If indeed "everything" 
needed to boot the OS is inside the FAT image, then at least 2 issues 
could be relevant:
_ the exact complete characteristics of the FAT image;
_ the exact complete command line used to build the ISO image.

There are more matters to consider, such as updating the firmware if 
there is such update available.

Feedback about tests with the binaries provided by Gene would be 
appreciated.

If Bruno wants to provide more details, perhaps we could be more 
useful.

Regards,
Ady.
 
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>