[syslinux] Isohybrid wiki page

Ady ady-sf at hotmail.com
Mon Apr 6 14:42:41 PDT 2015


> Hi,
> 
> Ady wrote:
> >  Hmm, but dd'ing isohybrid images is so simple...!
> >    You have the freedom to waste your time.
> 
> But dd-ing is the reason why isohybrid exists.
 
Context matters. Taking that quote out of its original context changes 
the way readers will interpret my intention.
 
> 
> Matthew Garrett extended the BIOS hard disk use case
> to UEFI in 2011 and 2012. hpa signed it off and committed
> it. See
>   http://git.kernel.org/cgit/boot/syslinux/syslinux.git/commit/utils/isohybrid.c?id=2c3a24e5f4b807ec31595227afa59a818c060ca9
>   http://git.kernel.org/cgit/boot/syslinux/syslinux.git/commit/utils/isohybrid.c?id=ead636d9693089bc54f1272552ae50b70d3f3965
> 
> Matthew's Fedora-LiveCD.iso of that time used GRUB 0.97
> in the ESP FAT image. I am quite sure that hpa and he
> would have used SYSLINUX instead if this had been possible.
> 
> It is time to face the facts.
> What cannot be dd-ed to the base device is no isohybrid.
 
>From my prior email with clear practical examples (in my Q&A), you can 
understand why I disagree.

Everyone building ISO(hybrid) images for public distribution using 
Syslinux 5.xx or 6.xx will tell you that mixing Syslinux versions is a 
bad idea. One way of assuring consistency is to distribute the adequate 
Syslinux binaries and their matching installers in the ISO(hybrid) 
image too.

Isohybrid images give the option to burn to optical media, or to dd' to 
(USB) drive. But it also leaves the possibility open to copy its 
content (whether scripted, or manually, or by means of auxiliary 
tools), without using dd-like methods. Key word: option. Whether the 
user actually uses dd' or a different method, it doesn't change the 
fact that the image is isohybrid.

Now, there are isohybrid images that are incompatible with methods 
other than dd'ing, and only optical media or dd-like methods are 
supported. Fine, but that's not because of isohybrid itself nor because 
Syslinux, but rather a choice of the original builder (e.g. 
kernel+initrd cannot boot from FAT media because the necessary "magic" 
is not in-there).

> So a wiki article about isohybrid must honestly state that
> UEFI isohybrid currently needs GRUB/GRUB2 (or a developer
> who fills the gap in SYSLINUX).

As my examples in my prior email clearly show, I would strongly 
disagree with such statement. I think I have expressed the current 
limitation(s) in various ways already, and it has to do with ISO9660. 
Saying "ISO9660" is not exactly the same as saying 'isohybrid", 
although they are related.

As a completely different example (and with no intention to open a new 
discussion), Debian 8 will "drop Syslinux integration" and will 
"recommend using a different bootloader if only EXTLINUX is installed". 
Those things have nothing to do with Syslinux itself. I know for a fact 
that some translators didn't understand the meaning of these phrases, 
and my guess is that some common users will interpret that Syslinux is 
no longer supported at all (or at least, discouraged). Whichever the 
intention is/was, the message is not clear enough IMHO.

Back to isohybrid, saying anything similar to "incompatibility" or 
"lack of support" between Syslinux and isohybrid would be misleading, 
and would potentially discourage valid methods for users to make use of 
images distributed as isohybrid.
 
> 
> Further one should probably state in the ISOLINUX wiki
> that there is no UEFI support for ISOs. No need to
> mention the competitors there. After all there is no
> ISOLINUX option for UEFI, other than with isohybrid.c.
 
We should also mention somewhere that there are no "chicken", no "beef" 
and no "veggies" for UEFI mode in The Syslinux Project :).
 
I think that my prior Q&A could be useful for some users. Next time 
I'll simply link to the public archived email. Adding every single 
thing that is not (yet?) included or supported will not end. Perhaps, 
should I also contact the FreeDOS community and ask for the 'sys.com' 
tool to include many more alternative VBR codes? And until they do, 
should they explicitly list all the possible VBR codes that are not yet 
included but could?
 
> 
> 
> 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