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
> 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.At this time I'd rather focus on syslinux.efi not being able to boot optical media in UEFI mode by means of the no-emulation method as described in the UEFI specs, instead of taking Pascal's case (and its resulting qemu's behavior) as base for testing other UEFI implementations.> > in previous post, Ady wrote: > > Is there anyone that is willing to add more options and alternatives > > to isohybrid [...] ? > > That's not easy.There is no developer that has attempted to answer the question of booting optical media in UEFI mode using syslinux.efi, in spite of years of being asked in this Syslinux mailing list, again and again. Let's first see syslinux.efi booting (virtual) optical media in UEFI mode using the so-called "efiboot.img" (super)floppy image as El Torito no-emulation, just as any other UEFI bootloader that claims to do so (and actually does). Only then, we can discuss whether there is a need for isohybrid changes, or whatever else might be needed / convenient. @Peter? Regards, Ady.
2016-12-23 13:56 GMT+01:00 Ady Ady 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. > > > At this time I'd rather focus on syslinux.efi not being able to boot > optical media in UEFI mode by means of the no-emulation method as > described in the UEFI specs, instead of taking Pascal's case (and its > resulting qemu's behavior) as base for testing other UEFI > implementations. >as syslinux.efi can not give the hand to the kernel located outside the image, I left this side to put everything in the image (vmlinux, initrd & syslinux.efi), but it stuck on isohybrid at the bios level now...> > > > > > in previous post, Ady wrote: > > > Is there anyone that is willing to add more options and alternatives > > > to isohybrid [...] ? > > > > That's not easy. > > There is no developer that has attempted to answer the question of > booting optical media in UEFI mode using syslinux.efi, in spite of > years of being asked in this Syslinux mailing list, again and again. >if everything is in the image, syslinux.efi can boot a linux kernel that will do the rest... at my level, with hard disk emulation, the problem lies in making the image iso bootable as a disk (eg. isohybrid).> > Let's first see syslinux.efi booting (virtual) optical media in UEFI > mode using the so-called "efiboot.img" (super)floppy image as El Torito > no-emulation, just as any other UEFI bootloader that claims to do so > (and actually does). Only then, we can discuss whether there is a need > for isohybrid changes, or whatever else might be needed / convenient. > > @Peter? > > Regards, > Ady. > > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >
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 >
Hi, i wrote:> > ... or an independent boot path via isolinux.bin and isohybrid.Pascal wrote:> what I'm trying to do is an hdd image that > contains the necessary to boot in bios/uefi modeThis is a prepared path only for BIOS from optical medium. The HDD image inside an ISO filesystem simply does not comply to UEFI specs. OVMF finds the EFI boot file by ignoring those specs. It might be possible to derive from the SYSLINUX project some x86 MBR code which hops onto an executable file that is able to find your HDD image and to hop onto the contained SYSLINUX code for BIOS. Have a nice day :) Thomas