[syslinux] syslinux mkisofs hard-disk-boot isohybrid

[Thomas Schmitt]

Hi,

Ady wrote:
> the UEFI specs do state that the ESP is supposed 
> to be set/used as no-emulation mode
> ...
> the UEFI specs should tolerate / accept this situation, rather than 
< restricting the ESP to no-emulation mode.

My criticism towards this UEFI implementation is that it probably cannot
serve as realistic test bed for the first stage of UEFI booting. It seems
far too tolerant towards standards deviations.

Not only does Pascal's working ISO bear a hard-disk-emulation boot image,
which constitutes a whole disk and not a disk partition, but also it is
not marked as Platform Id 0xEF. Still it is used by the EFI implementation
which he uses with his VM.

Especially weird is that El Torito has an effect when the ISO is presented
on hard disk. In this situation the UEFI specs prescribe that the ESP is
to be marked by MBR partition or GPT partition. But no partition table was
written to the start of the ISO image. (That would be the job of isohybrid
or a partition editor or mkisofs options like -G.)

Even if Unified EFI Inc. (or Intel) would be willing to widen the specs,
there is still the problem of existing implementations which took the
existing UEFI specs for serious.

--------------------------------------------------------------------------

Practically there is Pascal's initial obstacle of his ISO not booting
from hard disk via BIOS firmware.
To solve this problem, one could use MBR x86 code which chainloads the
MBR x86 code of the hard-disk-emulation image. mkisofs option -G would
put such code to the start of the ISO.

... or an independent boot path via isolinux.bin and isohybrid.
Like:

   -b .../isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table \
   -eltorito-alt-boot \
   -e boot/core.img -hard-disk-boot \

and then applying isohybrid _without_ its UEFI options.

isohybrid will add MBR x86 code which will hop on isolinux.bin. Of course
isolinux.bin then needs a configuration file in the ISO (not inside the
hard-disk-emulation image) and early operating system stages which enable
it to boot completely or to peek into the hard-disk-emulation image.

Well, at latest when somebody has to document the nature and reason of such
a boot equipment, it will be hard to justify it in the light of published
specs.

--------------------------------------------------------------------------

in previous post, Ady wrote:
> Is there anyone that is willing to add more options and alternatives
> to isohybrid [...] ?

That's not easy.
The original BIOS oriented isohybrid feature puts MBR x86 code to the start
of the ISO, which knows the block address of the isolinux.bin file in the ISO.
The MBR code just has to load that program and execute it. Then it is on
the same execution path as booting via El Torito from optical media.

But this cannot be done with a hard-disk-emulation image, because it is not
an executable program.
One would have to invent a whole new isohybridization mechanism, like hpa
invented isohybrid for isolinux.bin. Like the chainloading idea ... maybe.


Have a nice day :)

Thomas