Hi, piranna wrote:> > Quoting http://www.syslinux.org/wiki/index.php/Isohybrid#UEFI: > > "The additional isohybrid feature for UEFI adds a partition to the MBR > > partition table pointing to the same file in the ISO 9660 filesystem > > as does the El Torito catalog entry for EFI."Ady wrote:> IMHO, the current content of the Isohybrid page in the Syslinux Wiki is > not clear enough [...] The current generic information is > rather focused on _potential_ capabilities of _isohybrid_ tools and > some of their internal technical characteristics, and less focused on > actual practical steps for ends users.Well, it is about really usable capabilities of isohybrid, which regrettably only work with EFI boot software from other bootloader projects. isohybrid can mark a FAT filesystem image with EFI boot software as EFI System Partition inside the ISO image. But SYSLINUX cannot provide a FAT image with EFI boot software that works with an ISO 9660 filesystem. All EFI isohybrid images known to me contain /efi/boot/bootx64.efi from GRUB Legacy or GRUB2. About fixing the wiki: Would it be appropriate to mention the words "GRUB legacy" and "GRUB2" in the SYSLINUX wiki ? Would it be desirable to explain how Fedora et.al. created their FAT boot images by help of old or new GRUB ? (If developers of EFI bootable ISOs are reading this, please give a short sketch of the procedure.) piranna wrote:> > (iso9660 can be seen as a read-only FAT filesystem)?The meta-data structures of ISO 9660 are different from FAT. Have a nice day :) Thomas
> Hi, > > piranna wrote: > > > Quoting http://www.syslinux.org/wiki/index.php/Isohybrid#UEFI: > > > "The additional isohybrid feature for UEFI adds a partition to the MBR > > > partition table pointing to the same file in the ISO 9660 filesystem > > > as does the El Torito catalog entry for EFI." > > Ady wrote: > > IMHO, the current content of the Isohybrid page in the Syslinux Wiki is > > not clear enough [...] The current generic information is > > rather focused on _potential_ capabilities of _isohybrid_ tools and > > some of their internal technical characteristics, and less focused on > > actual practical steps for ends users. > > Well, it is about really usable capabilities of isohybrid,Which is the same as what I just said, "potential capabilities". Yes, they are real capabilities already present at least in some of the isohybrid tools, but their practical combination, usage, effects, goals... are not expressed clearly enough for the common user to put in practice. As an example of what I am trying to convey, we could explain to users the (long and boring) technical details of how SYSLINUX boots, or we could write "execute the extlinux command with this and that parameters".> which regrettably only work with EFI boot software from > other bootloader projects.Which is, again, the same as what I just said, that is, not actually stating to common users "these are the steps, and these are the commands so to arrive to X goal (aka "HowTo").> > isohybrid can mark a FAT filesystem image with EFI > boot software as EFI System Partition inside the ISO > image. But SYSLINUX cannot provide a FAT image with > EFI boot software that works with an ISO 9660 filesystem.And this is part of the conflicting information. The "efi.img" is what GRUB2 does, which doesn't mean that every bootloader must use the same method (nor that Syslinux currently supports all potential use-cases of any-and-every resulting isohybrid image). Although the above paragraph is not completely inaccurate, it slightly, but wrongly, suggests that this is how everyone should try to achieve the goal, using the same method and that the 'syslinux.efi' is lacking such "important" feature. Let me present a hypothetical different method. Please bear in mind that I am not trying to present a complete perfectly thought method, but instead I am only trying to expose the potential chance that some other method, different from what GRUB2 does, could exist. In other words, the following very-generic idea could very well not be really feasible, but please follow me anyway :). So. Let's assume that 'syslinux.efi' receives support for ISO9660 and for UDF in some future version. Let's assume also that the "multifs" features are eventually incorporated too (after all, there were already initial attempts with suggested "multifs" patches, for more than one branch of Syslinux). With these made-up assumptions, the ISO image could have the same "EFI/BOOT/BOOTX64.EFI" (renamed from "syslinux.efi") and use it to boot in UEFI mode, whether we use the ISO image on optical media, dd'ed on a USB flash drive, or copied on a FAT-formatted volume. In this hypothetical situation, there is no need for an "efi.img" to be included in the ISO image. So, from this made-up situation, we could write a more accurate statement: "GRUB2 uses a so-called "efiboot.img as method to...". There is no standard / specification / convention that imposes for this to be "the" (only) method. It is true that Syslinux currently lacks the possibility to boot ISO9660 media in UEFI mode (whether in optical media or in some dd'ed USB flash drive or similar ISO9660 media), but it doesn't mean that Syslinux must follow the same "efi*.img" method of GRUB2 to achieve the goal.> > All EFI isohybrid images known to me contain > /efi/boot/bootx64.efi from GRUB Legacy or GRUB2.For some hypothetical support of UEFI booting optical media and/or dd'ed isohybrid images, yes, that is currently the case in the Linux world. But if I would want to use a FAT-formatted ESP, I could use 'syslinux.efi' (and/or others too), whether the ISO image is "isohybrid" or not.> > > About fixing the wiki: > > Would it be appropriate to mention the words "GRUB legacy" > and "GRUB2" in the SYSLINUX wiki ? > > Would it be desirable to explain how Fedora et.al. > created their FAT boot images by help of old or new > GRUB ? > (If developers of EFI bootable ISOs are reading this, > please give a short sketch of the procedure.)I have nothing against any bootloader, but IMHO it would not be appropriate to add to the same Isohybrid page in the official Syslinux wiki all this data. My reasoning about it is not really subjective, on the contrary. One of the reasons users keep asking *to The Syslinux Project* questions about some "efi*.img in some ISO image for UEFI booting" is because most posts / articles / blogs... are not clear enough about what they present as "UEFI boot". They tend to mix, without clear discernment, "UEFI specs" together with "the way GRUB2 does it" and with "the way X maintainer resolved Y problem in this Z distro", plus "let's help owners of some popular hardware with some not-so-standard (U)EFI firmware". Then they present this salad with some additional (and frequently inadequate / inaccurate) condiment and they tell their users / readers: eat this, is _that_ "simple". In the past I have already expressed my opinion regarding the target readers and the level of information for this Isohybrid wiki page. Just as (an exaggerated) example, the "Mbr" page in the Syslinux wiki is not the same as the "Master Boot Record" page in the same Syslinux wiki and certainly it is very different than the "Master Boot Record" page in Wikipedia (i.e. the first one has a different target reader and a different purpose than the last two). While the "Mbr" page in the Syslinux wiki is far from perfect, it is mainly focused on practical steps: which '*mbr*.bin' file to choose according to user's needs and how to use it. In comparison, the "Master Boot Record" page in Wikipedia is so long and covers so many details that a common user would rather keep using the OS that came pre-installed in his computer and never get even close to an alternative "bootable media" of any kind. (That is not to say that the Wikipedia article is not useful; it is indeed.) So, my suggestion for the wiki would be different (although, part of the following info is already there), not necessarily presented in this order and not all in one page: _ clearly present generic capabilities of "isohybrid" images; _ differentiate what _isohybrid_ itself can and cannot do and what feature / characteristic / capability depends on each/the/some/any/ bootloader used in the image (special attention on limitations too); _ clarify the existence of different isohybrid variants and their respective relation to popular ISO-building tools; _ present the command line options with a minimal very short description, linking to man pages and similar official documentation for further reading; _ generic examples of isohybrid steps / commands; _ Optional: "See also" with links to updated official support information provided by popular well-documented distros; _ Optional: "See also" with popular articles / HowTos / other wikis related to isohybrid, whether they are related to different hardware (PC+Macs+PPC with BIOS) or related to alternative firmware (BIOS+UEFI), or different booting media (USB flash drive + optical media) or related to any combination of those. For the practical sections to be helpful, the more-theoretical parts should not be mixed with them, and probably they would be better located in separated (sub)pages. In fact, almost all the above points could be considered optional. I certainly would _not_ repeat detailed information that can be found elsewhere (e.g. Wikipedia, UEFI specs, partition editor's manuals...). I would also not specify how "this or that distro" does it, as the particular steps (or even the technical information) can change without notice. We don't want to maintain unnecessary information, nor receive complaints that the info in the Syslinux wiki is "wrong because they are not longer doing it that way" or "the procedure is wrong for version 'n' of my distro). Even links to specific distros are problematic, as sometimes new official support information is posted in different pages than the older info and the links would be kept alive and only-seemingly relevant, while in practice the distro might have published updated information in a different place. I'd rather not publish links to specific distros, and let users make use of relevant search engines. Unfortunately, there is a tendency for users to approach The Syslinux Project with questions that should be placed to their respective communities. I'd rather not encourage such behavior.> > > Have a nice day :) > > ThomasRegards, Ady.> > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >
Hi, i wrote:> > Well, it is about really usable capabilities of isohybrid,Ady wrote:> but their practical combination, usage, effects, > goals... are not expressed clearly enough for the common user to put in > practice.How to express the embarrassing fact that ISOLINUX is not ready for UEFI but isohybrid is ? http://www.syslinux.org/wiki/index.php/Isohybrid#UEFI would need a statement like: "The SYSLINUX project cannot yet provide a FAT filesystem image which would work with the isohybrid feature. Known isohybrid ISOs for UEFI employ FAT images which contain software from bootloader projects GRUB or GRUB2." This would not help any user, of course, without a clue how to make the necessary FAT image.> stating to common users "these are the steps, and these are the > commands so to arrive to X goal (aka "HowTo").I do not know how the maintainers of distro ISO production produce their FAT images. I know that they contain GRUB/GRUB2 software. Fedora's FAT /isolinux/efiboot.img based on GRUB Legacy (0.97) seems to contain some configuration files. Debian's FAT image /boot/grub/efi.img contains only the UEFI-defined start program /efi/boot/bootx64.efi from GRUB2 (1.99).> The "efi.img" is what > GRUB2 does, which doesn't mean that every bootloader must use the same > method (nor that Syslinux currently supports all potential use-cases of > any-and-every resulting isohybrid image).The image file name is at the discretion of the ISO producer. Its formatting as MS-DOS-ly FAT filesystem image and the FAT path /efi/boot/bootx64.efi are prescribed by UEFI specs. The program bootx64.efi is supposed to start the boot process. I understand from the sparse content of Debian's amd64 FATs that GRUB2's bootx64.efi can interpret ISO 9660 and find its configuration files in there.> wrongly, suggests [...] that the 'syslinux.efi' is lacking > such "important" feature.This is what i understand from SYSLINUX being unable to boot from ISO 9660 via UEFI. The EFI related software of SYSLINUX seems not to be prepared to work with ISO 9660 after it was started from the FAT in the EFI System Partition.> Let's assume that 'syslinux.efi' receives support for ISO9660 and > for UDF in some future version.UDF is more complicated than ISO 9660 and not much in use for bootable images. Support for ISO 9660 in SYSLINUX EFI software would be great, because EFI specs explicitely mention the boot path via El Torito on optical media. UEFI 2.4 9.3.6.2: "The CD-ROM is assumed to contain an ISO-9660 file system and follow the CD-ROM El Torito format."> In this hypothetical situation, there is no need > for an "efi.img" to be included in the ISO image.http://www.uefi.org/sites/default/files/resources/2_4_Errata_B.pdf chapter 5 defines the expectations of UEFI. For booting UEFI from optical medium, you need an El Torito catalog entry for Platform Id 0xef pointing to the FAT filesystem. Traditionally the El Torito boot images are data files inside the ISO filesystem. But they could as well be appended to the image after the end of the ISO filesystem. For booting UEFI from USB stick you need the FAT filesystem in a partition (the EFI System Partition). UEFI 2.4 offers two forms of partitioning: - Legacy: One to four MBR partitions. One of them bears the type 0xef. - GPT: Only one MBR partition, starting at LBA 1 and ending at the end of the ISO image. It must bear type 0xee. The EFI System partition is then marked by a GPT partition with type GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B Both alternatives demand neat partitioning. Especially no nested partitions. isohybrid violates UEFI by combining both methods and by nesting partitions. The motivation for this is given by Matthew Garrett in http://mjg59.dreamwidth.org/11285.html I made a lengthy analysis about Debian's sins and improvement options in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776317#75> With these made-up assumptions, the ISO image > could have the same "EFI/BOOT/BOOTX64.EFI"UEFI 2.4. does not promise any capability of the firmware about ISO 9660, except the capability to recognize and interpret El Torito boot sector and El Torito catalog. The magic (architecture dependent) path EFI/BOOT/BOOTX64.EFI must be presented inside a FAT filesystem.> > All EFI isohybrid images known to me contain > > /efi/boot/bootx64.efi from GRUB Legacy or GRUB2.> For some hypothetical support of UEFI booting optical media and/or > dd'ed isohybrid images, yes, that is currently the case in the Linux > world. But if I would want to use a FAT-formatted ESP, I could use > 'syslinux.efi' (and/or others too), whether the ISO image is > "isohybrid" or not.Of course, piranna could set up an EFI capable disk boot image by help of SYSLINUX. But that would not boot from optical media. The EFI isohybrid feature is to mark the ESP by both, El Torito and partition table.> I have nothing against any bootloader, but IMHO it would not be > appropriate to add to the same Isohybrid page in the official Syslinux > wiki all this data.It currently boils down to: No GRUB = no UEFI from ISO 9660.> posts / articles / blogs [...] tend to mix, without clear > discernment, "UEFI specs" together with "the way GRUB2 does it"It is not that GRUB would do something special with booting UEFI (except that the ISOs made by grub-mkrescue have the prescribed neat partition tables). It is rather that no way is known how to let SYSLINUX understand the ISO 9660 filesystem outside of its ESP. (Ain't there any way to put enough ISOLINUX brain into the ESP so that it is smart enough ?)> _ clearly present generic capabilities of "isohybrid" images;ISOLINUX-only isohybrid is only suitable for BIOS firmware.> _ differentiate what _isohybrid_ itself can and cannot doIt equips ISO 9660 filesystem images with partition tables which point to the software for the initial boot stage. It cannot create the FAT image for the EFI System Partition.> _ clarify the existence of different isohybrid variantsI think that this is explained in wiki/index.php/Isohybrid. (But it is not explained *why* there are still two isohybrid programs in the SYSLINUX releases.)> _ present the command line options with a minimal very short > description, linking to man pages and similar official documentation > for further reading;The only non-expert option is --uefi. There is no further non-expert documentation known to me.> _ generic examples of isohybrid steps / commands;For BIOS-only, the user makes the ISO according to http://www.syslinux.org/wiki/index.php/ISOLINUX and applies the isohybrid program. Or the user makes the ISO by xorriso and lets it do the job of isohybrid already when creating the ISO. For UEFI there are examples with genisoimage and xorriso in wiki/index.php/Isohybrid, plus a mkisofs equivalent of genisoimage option -e.> _ Optional: "See also" with links to updated official support > information provided by popular well-documented distros; > _ Optional: "See also" with popular articles / HowTos / other wikis > related to isohybrid,There are none. At least not on user level.> Unfortunately, there is a tendency for users to approach The Syslinux > Project with questions that should be placed to their respective > communities. I'd rather not encourage such behavior.The communities are hardly of help with boot topics. Typically you only get a collection of urban legends as reply. Those who know do neither document nor hang out at the support forums. Have a nice day :) Thomas
> Would it be desirable to explain how Fedora et.al. > created their FAT boot images by help of old or new > GRUB ? > (If developers of EFI bootable ISOs are reading this, > please give a short sketch of the procedure.)I did it by including the Linux kernel and the initramfs, but that's sub-optimal since I need to have them in two places. That's why I asked about re-using the same MBR entry so no need for an EFI image, or have a basic minimal one capable of piggy-back the real one that could be included in IsoLinux (or isoHybrid) source code.>> > (iso9660 can be seen as a read-only FAT filesystem)? > > The meta-data structures of ISO 9660 are different from > FAT.Oh, you are right, that's enought for being incompatible, sorry :-( -- "Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." ? Linus Tordvals, creador del sistema operativo Linux
Hi, i wrote:> > Would it be desirable to explain how Fedora et.al. > > created their FAT boot images by help of old or new > > GRUB ? > > (If developers of EFI bootable ISOs are reading this, > > please give a short sketch of the procedure.)piranna at gmail.com wrote:> I did it by including the Linux kernel and the initramfsNone of the ISOs i know has this stuff in the FAT image. There must be some way for GRUB/GRUB2 to escape from FAT into the ISO. debian-7.7.0-amd64-netinst.iso does the job by a bootx64.efi binary of 421888 bytes. It's the only file in the FAT (of 458752 bytes). It might be a workaround for ISOLINUX to bring ISOLINUX configuration and a minimal Linux into the FAT which is then able to start the desired operating system from the ISO.> but that's sub-optimal since I need to have them in two places.Especially since the size of an El Torito boot image is restricted to 32 MiB (65536 x 512 bytes).> That's why I > asked about re-using the same MBR entry so no need for an EFI imageEFI ignores the boot code in the MBR and only follows the partition table entry of type 0xef, if there is any. In any case there is no other boot path specified than to look up /efi/boot/bootx64.efi in the FAT filesystem and to execute it. Only the methods of finding the FAT differ, depending on the medium type (El Torito vs. partition table) and on the choice of the partition table (MBR vs. GPT). Have a nice day :) Thomas