[syslinux] syslinux mkisofs hard-disk-boot isohybrid

[Pascal]

2016-12-23 9:20 GMT+01:00 Thomas Schmitt via Syslinux <syslinux at zytor.com>:

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

it is indeed a solution but it leads to duplicate the kernel (and initrd)
in the "image" and in the "iso"... what I'm trying to do is an hdd image
that contains the necessary to boot in bios/uefi mode (eg. gptmbr, esp,
syslinux.uefi, syslinux.bios, kernel, initrd) and to boot it from an iso
image which can be burned on a optical disc or written to a usb stick...


>
> 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
>
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>