[syslinux] Isohybrid wiki page WAS: Is efiboot.img required?

Ady ady-sf at hotmail.com
Sun Apr 5 02:04:06 PDT 2015


> Hi,
> 
> piranna wrote:
> > > Quoting http://www.syslinux.org/wiki/index.php/Isohybrid#UEFI:
> > > "The additional isohybrid feature for UEFI adds a partition to the MBR
> > > partition table pointing to the same file in the ISO 9660 filesystem
> > > as does the El Torito catalog entry for EFI."
> 
> Ady wrote:
> > IMHO, the current content of the Isohybrid page in the Syslinux Wiki is 
> > not clear enough [...]  The current generic information is 
> > rather focused on _potential_ capabilities of _isohybrid_ tools and 
> > some of their internal technical characteristics, and less focused on 
> > actual practical steps for ends users.
> 
> Well, it is about really usable capabilities of isohybrid,
 
Which is the same as what I just said, "potential capabilities". Yes, 
they are real capabilities already present at least in some of the 
isohybrid tools, but their practical combination, usage, effects, 
goals... are not expressed clearly enough for the common user to put in 
practice.

As an example of what I am trying to convey, we could explain to users 
the (long and boring) technical details of how SYSLINUX boots, or we 
could write "execute the extlinux command with this and that 
parameters".
 
> which regrettably only work with EFI boot software from
> other bootloader projects.
 
Which is, again, the same as what I just said, that is, not actually 
stating to common users "these are the steps, and these are the 
commands so to arrive to X goal (aka "HowTo").
 
> 
> isohybrid can mark a FAT filesystem image with EFI
> boot software as EFI System Partition inside the ISO
> image.  But SYSLINUX cannot provide a FAT image with
> EFI boot software that works with an ISO 9660 filesystem.
 
And this is part of the conflicting information. The "efi.img" is what 
GRUB2 does, which doesn't mean that every bootloader must use the same 
method (nor that Syslinux currently supports all potential use-cases of 
any-and-every resulting isohybrid image). Although the above paragraph 
is not completely inaccurate, it slightly, but wrongly, suggests that 
this is how everyone should try to achieve the goal, using the same 
method and that the 'syslinux.efi' is lacking such "important" feature.

Let me present a hypothetical different method. Please bear in mind 
that I am not trying to present a complete perfectly thought method, 
but instead I am only trying to expose the potential chance that some 
other method, different from what GRUB2 does, could exist. In other 
words, the following very-generic idea could very well not be really 
feasible, but please follow me anyway :).

So. Let's assume that 'syslinux.efi' receives support for ISO9660 and 
for UDF in some future version. Let's assume also that the "multifs" 
features are eventually incorporated too (after all, there were already 
initial attempts with suggested "multifs" patches, for more than one 
branch of Syslinux). With these made-up assumptions, the ISO image 
could have the same "EFI/BOOT/BOOTX64.EFI" (renamed from 
"syslinux.efi") and use it to boot in UEFI mode, whether we use the ISO 
image on optical media, dd'ed on a USB flash drive, or copied on a 
FAT-formatted volume. In this hypothetical situation, there is no need 
for an "efi.img" to be included in the ISO image.

So, from this made-up situation, we could write a more accurate 
statement: "GRUB2 uses a so-called "efiboot.img as method to...". There 
is no standard / specification / convention that imposes for this to be 
"the" (only) method. It is true that Syslinux currently lacks the 
possibility to boot ISO9660 media in UEFI mode (whether in optical 
media or in some dd'ed USB flash drive or similar ISO9660 media), but 
it doesn't mean that Syslinux must follow the same "efi*.img" method of 
GRUB2 to achieve the goal.
 
> 
> All EFI isohybrid images known to me contain
> /efi/boot/bootx64.efi from GRUB Legacy or GRUB2.
 
For some hypothetical support of UEFI booting optical media and/or 
dd'ed isohybrid images, yes, that is currently the case in the Linux 
world. But if I would want to use a FAT-formatted ESP, I could use 
'syslinux.efi' (and/or others too), whether the ISO image is 
"isohybrid" or not.
 
> 
> 
> About fixing the wiki:
> 
> Would it be appropriate to mention the words "GRUB legacy"
> and "GRUB2" in the SYSLINUX wiki ?
> 
> Would it be desirable to explain how Fedora et.al.
> created their FAT boot images by help of old or new
> GRUB ?
> (If developers of EFI bootable ISOs are reading this,
>  please give a short sketch of the procedure.)
 
I have nothing against any bootloader, but IMHO it would not be 
appropriate to add to the same Isohybrid page in the official Syslinux 
wiki all this data. My reasoning about it is not really subjective, on 
the contrary.

One of the reasons users keep asking *to The Syslinux Project* 
questions about some "efi*.img in some ISO image for UEFI booting" is 
because most posts / articles / blogs... are not clear enough about 
what they present as "UEFI boot". They tend to mix, without clear 
discernment, "UEFI specs" together with "the way GRUB2 does it" and 
with "the way X maintainer resolved Y problem in this Z distro", plus 
"let's help owners of some popular hardware with some not-so-standard 
(U)EFI firmware". Then they present this salad with some additional 
(and frequently inadequate / inaccurate) condiment and they tell their 
users / readers: eat this, is _that_ "simple".

In the past I have already expressed my opinion regarding the target 
readers and the level of information for this Isohybrid wiki page.

Just as (an exaggerated) example, the "Mbr" page in the Syslinux wiki 
is not the same as the "Master Boot Record" page in the same Syslinux 
wiki and certainly it is very different than the "Master Boot Record" 
page in Wikipedia (i.e. the first one has a different target reader and 
a different purpose than the last two). While the "Mbr" page in the 
Syslinux wiki is far from perfect, it is mainly focused on practical 
steps: which '*mbr*.bin' file to choose according to user's needs and 
how to use it. In comparison, the "Master Boot Record" page in 
Wikipedia is so long and covers so many details that a common user 
would rather keep using the OS that came pre-installed in his computer 
and never get even close to an alternative "bootable media" of any 
kind. (That is not to say that the Wikipedia article is not useful; it 
is indeed.)

So, my suggestion for the wiki would be different (although, part of 
the following info is already there), not necessarily presented in this 
order and not all in one page:

_ clearly present generic capabilities of "isohybrid" images;

_ differentiate what _isohybrid_ itself can and cannot do and what 
feature / characteristic / capability depends on each/the/some/any/ 
bootloader used in the image (special attention on limitations too);

_ clarify the existence of different isohybrid variants and their 
respective relation to popular ISO-building tools;

_ present the command line options with a minimal very short 
description, linking to man pages and similar official documentation 
for further reading;

_ generic examples of isohybrid steps / commands;

_ Optional: "See also" with links to updated official support 
information provided by popular well-documented distros;

_ Optional: "See also" with popular articles / HowTos / other wikis 
related to isohybrid, whether they are related to different hardware 
(PC+Macs+PPC with BIOS) or related to alternative firmware (BIOS+UEFI), 
or different booting media (USB flash drive + optical media) or related 
to any combination of those.

For the practical sections to be helpful, the more-theoretical parts 
should not be mixed with them, and probably they would be better 
located in separated (sub)pages. In fact, almost all the above points 
could be considered optional.

I certainly would _not_ repeat detailed information that can be found 
elsewhere (e.g. Wikipedia, UEFI specs, partition editor's manuals...). 
I would also not specify how "this or that distro" does it, as the 
particular steps (or even the technical information) can change without 
notice. We don't want to maintain unnecessary information, nor receive 
complaints that the info in the Syslinux wiki is "wrong because they 
are not longer doing it that way" or "the procedure is wrong for 
version 'n' of my distro).

Even links to specific distros are problematic, as sometimes new 
official support information is posted in different pages than the 
older info and the links would be kept alive and only-seemingly 
relevant, while in practice the distro might have published updated 
information in a different place. I'd rather not publish links to 
specific distros, and let users make use of relevant search engines.

Unfortunately, there is a tendency for users to approach The Syslinux 
Project with questions that should be placed to their respective 
communities. I'd rather not encourage such behavior.
 
> 
> 
> Have a nice day :)
> 
> Thomas
 
Regards,
Ady.
 
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> 




More information about the Syslinux mailing list