[syslinux] Isohybrid wiki page and UEFI

Ady ady-sf at hotmail.com
Fri Oct 30 04:06:45 PDT 2015


> Ady wrote:
> > The reason genisoimage is highly modified is because... It is 
> > unmaintained!
> 
> Sad but true. The cdrkit website is gone. Most "original" is
> the debian source package.
> 
> 
> > The "real" genisoimage (and any reincarnation of 
> > it) might never work with Syslinux; who knows?
> 
> It works fine for BIOS purposes, assisted by a run of isohybrid,
> if desired.
> The Debian version has no means to express other El Torito
> Platform Ids than number 0 ("80x86" as of El Torito 1.0).
> This is done by using option -b.
> 
> 
> > I cannot see any good reason to keep testing (Syslinux) with 
> > "genisoimage".
> 
> Bruno obviously uses genisoimage from Fedora or RedHat, which
> has options -e and -efi-boot.
> The output from this program suffices for EFI purposes, as
> i can tell from the output of xorriso -report_el_torito:
 
Once again, we are troubleshooting syslinux.efi in a FAT1x image for 
booting optical media in UEFI mode. I cannot understand the logic of 
using a code (patched or not) that has not been maintained since 2010 
and that has not been tested with syslinux.efi.

Although RH and Fedora have info and code for booting in UEFI mode, 
there is no document that is clear about the "independence" of boot 
loader in the procedures. Every document from RH / Fedora that _I_ have 
read about UEFI also includes some kind of mixed information; for 
instance, assuming GRUB2 as bootloader without clearly discerning what 
is "UEFI" text and what is "GRUB2" text / procedures. One of the 
consequences is that some users coming here, to the Syslinux Mailing 
List, confuse / mix the procedures for GRUB2 (or that happen to work 
successfully with it) with those for "booting in UEFI mode", thus 
"extending" what they (think they) know / understand to the way they 
assume Syslinux is supposed to work.

A similar situation happens when some users (wrongly) base their 
expectations on their prior experience with booting some MS' OS (in 
UEFI mode).

So, I'm glad "genisoimage" works for some UEFI scenarios (with certain 
bootloaders). But, could we please avoid assuming that an unmaintained 
code (since 2010) is %100 adequate for booting syslinux.efi? It might, 
or might not. We would had to accept such situation if we had no other 
alternatives, but we do.

Sincerely, I think it is... unfair? to ask (in one way or another) from 
people in this Syslinux Mailing List to invest time while refusing to 
use an adequate setup or relevant tools.

If we solve the current issue, then anyone is free to go back and use 
any code, including an unmaintained one. In fact, anyone is also free 
to do it now too, but I would be less inclined to invest my own 
personal time.

In other words, we should be narrowing down the source of the problem, 
but using genisoimage at this troubleshooting stage goes against such 
direction.
 
> 
> > El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
> > El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4       15035
> > El Torito boot img :   2  UEFI  y   none  0x0000  0x00  60000          35
> > El Torito img path :   1  /isolinux.bin
> > El Torito img opts :   1  boot-info-table isohybrid-suitable
> > El Torito img path :   2  /1.img
> 
> The file /1.img is properly advertised as EFI System Partition,
> beginning at byte 35 * 2048 and covering 60000 * 512 bytes. 
> 
> Any problem with booting must sit inside file /1.img.
 
But you are forgetting my other comments about the FAT image for 
booting optical media in UEFI mode. Some firmware might work with some 
images, and some might not, so let's use the basics for 
troubleshooting, according to UEFI Specs. KISS.
 
> 
> 
> > No, again, the UEFI-required FAT image for booting optical media does 
> > not need (nor want, nor accept, nor use) any kind of partitioning 
> > scheme.
> 
> Although i fully agree to KISS, i believe that a compliant EFI
> implementation should be able to stand a MBR/EBR in the system
> partition.
> 
> UEFI 2.6, 1.3 Goals: 
> "The design of the system partition structures also preserves all the
>  structures that are currently used in the “PC-AT” boot environment.
>  Thus, it is a simple matter to construct a single system that is
>  capable of booting a legacy OS or an EFI-aware OS from the
>  same disk."
> 
> A partition MBR (EBR) is not unusual on PC disks. The topic of
> chainloading is associated with them.
> 
> UEFI 2,6, 12.3.1 System Partition:
> "A System Partition supports backward compatibility with legacyi
>  systems by reserving the first block (sector) of the partition
>  for compatibility code."
> 
> I interpret "reserving" as "not interpreting", which matches the
> expressed goal of compatibility.
> Not storing own stuff at block 0 is a common property of many
> filesystems.
> 
 
But context matters. I am not talking about a generic ESP. I am talking 
about the FAT image expected / used for booting optical media in UEFI 
mode. Such case is not supposed to use a partitioning scheme.
 
> 
> > Now, regarding (additional) partitioning schemes being added by 
> > isohybrid,
> 
> Bruno's ISO does not contain isohybrid info. It is pure El Torito
> suitable for (maybe virtual) optical media only.
 
And yet, he mentioned (more than once) a MBR being somewhere in there.
 
> 
> An isohybrid run with option --uefi would equip the ISO with
> MBR and GPT. Then it could be tested on hard disk or USB stick.
 
But we are focusing our efforts on booting optical media in UEFI mode 
with syslinux.efi. There is no reason at this point to add more 
variables / aspects that could go wrong in some unknown way, especially 
when dealing with firmware. KISS.
 
> See wiki example:
>   isohybrid --uefi output.iso
> 
> This test would show whether the problem is with ISO 9660
> or with optical media (and their block size 2048).
> (I dimly remember it was declared an ISO issue.)
> 
 
Which test? Do you mean by dd'ing an isohybrid image to a USB flash 
drive (for instance)? In this email thread I have only read about the 
intention to boot optical media in UEFI mode. If the latter doesn't 
work, I doubt the former can.

If the block size of 2048 is a problem, then is there any reason to 
assume that a block size of 512, or 4096, would work differently? In 
such context, I would suggest testing with the FAT12 image I attached 
in my previous email, as it is at least aligned to 2048 bytes.
 
> 
> 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