> 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
>