[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