[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