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
> 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.htmlThere it says about creating a third El Torito image only for Macs, since old ones could fail and this could be the problem I'm having. I've used the --mac option of IsoHybrid and it's demanding another disk image, so this should be documented too...>> > 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.This is what I've done, a FAT disk image with syslinux.efi and embed it inside the IsoHybrid disk image, but when dd'd to the USB pendrive, SysLinux.efi loads the Linux kernel and its initramfs file but doesn't boot... :-/ As I put in the initial message I'm not using the /efi/boot/bootx64.efi path but instead just copied all files in the root directory of the FAT disk image, but since it already load the kernel and the initramfs maybe the canonical path is not required... is it? Do I need to use the canonical one (and why)?>> _ differentiate what _isohybrid_ itself can and cannot do > > It 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.Also add instructions about how to create a FAT image... and maybe add the hability to craft it with IsoLinux/SysLinux/syslinux.efi instead of depending to GRUB2 or other bootloaders, ideally by piggy-back over the real ISO9660 partition (syslinux.efi is the ideal candidate to support that, but maybe it could be better a custom bootloaded that only do this task?).>> _ 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.I think --mac could fall in this topic too.>> _ 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.Info about creation of the FAT disk image, and if there's any diference (that seems there are), example for EFI-based Macs. -- "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:> > http://mjg59.dreamwidth.org/11285.htmlpiranna at gmail.com wrote:> There it says about creating a third El Torito image only for Macs, > since old ones could fail and this could be the problem I'm having.The third boot image is HFS+, not FAT. I understand this is for pre-EFI Macs. Try a Debian amd64 ISO, e.g.: http://cdimage.debian.org/debian-cd/7.8.0/amd64/iso-cd/debian-7.8.0-amd64-netinst.iso It does not have a HFS+ boot image, other than Fedora-LiveCD.iso.> > Of course, piranna could set up an EFI capable disk boot > > image by help of SYSLINUX. But that would not boot from > > optical media.> This is what I've done, a FAT disk image with syslinux.efi and embed > it inside the IsoHybrid disk image, but when dd'd to the USB pendrive,I meant a disk-only image. No ISO, no hybrid. Just an ESP and an operating system partition. Created by partition editor, filesystem formatter, and populated with files by you and SYSLINUX.> SysLinux.efi loads the Linux kernel and its initramfs file but doesn't > boot... :-/ As I put in the initial message I'm not using the > /efi/boot/bootx64.efi path but instead just copied all files in the > root directory of the FAT disk image, but since it already load the > kernel and the initramfs maybe the canonical path is not required... > is it? Do I need to use the canonical one (and why)?I would have expected that EFI falls back to the EFI shell if no /efi/boot/bootx64.efi is present in the ESP. Hrmpf ... The file names are defined in 3.4.1.1 "Removable Media Boot Behavior". In general, the file paths can be set by a NVRAM variable (FilePathList[0] ?) for particular devices. Do you have indications that syslinux.efi was really executed ?> > The only non-expert option is --uefi. > > There is no further non-expert documentation known to me.> I think --mac could fall in this topic too.Cough. I still riddle how to describe UEFI. HFS+ for old Macs would introduce the topic of file blessing. Not to speak of the fact that no tangible info is available about the range of Macs which need it.> Info about creation of the FAT disk image, and if there's any > diference (that seems there are), example for EFI-based Macs.First we would have to produce a SYSLINUX based ESP image which is able to boot Linux so that it can use the surrounding ISO 9660 filesystem. Have a nice day :) Thomas
Hi, i wrote:> > Does EFI just guess "Syslinux" from "syslinux.efi" ?piranna at gmail.com wrote:> Maybe EFI, but I think it's rEFInd, > http://www.rodsbooks.com/refind/Oh, a man in the middle with extra brains. This explains a lot.>From what storage device does it boot ? (From hard disk ?)Will it be present with the production images ?> > I really cannot read this behavior from UEFI 2.4 specs. > Maybe it's because it's the only one .efi file?It's because i thought that EFI firmware would be the one which finds syslinux.efi. Of course rEFInd can follow its own rules and offer own capabilities. --------------------------------------------------------- The discussion wandered out of my scope as ISO producer. I am still interested in improving the isohybrid wiki and will watch for pointers to descriptions of the FAT production process (with GRUB/GRUB2 if not with SYSLINUX). If no such descriptions appear within the next weeks, then i plan to state in http://www.syslinux.org/wiki/index.php/Isohybrid#UEFI "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 software boots by own non-SYSLINUX configurations." It would be nice, of course, if the statement could present SYSLINUX UEFI isohybrid as being more autonomous. Have a nice day :) Thomas
> > I am still interested in improving the isohybrid wiki > and will watch for pointers to descriptions of the FAT > production process (with GRUB/GRUB2 if not with SYSLINUX). > > If no such descriptions appear within the next weeks, > then i plan to state in > http://www.syslinux.org/wiki/index.php/Isohybrid#UEFI > > "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 software boots by own non-SYSLINUX configurations." > > It would be nice, of course, if the statement could present > SYSLINUX UEFI isohybrid as being more autonomous. > > > Have a nice day :) > > Thomas >IMHO, this seems somewhat inaccurate, or at least not entirely clear for users that don't already have the necessary knowledge about what we are talking about. This could be misinterpreted by some users as: "if you want to build an isohybrid image, then you cannot use 'syslinux.efi'". This would be incorrect. There is no incompatibility between 'syslinux.efi' and isohybrid images. The apparent limitation, if someone wants to call it that way, is that 'syslinux.efi' does not make use of "efiboot.img" as GRUB2 does. Currently (as of v.6.03) 'syslinux.efi' is not capable of booting optical media (or any media using ISO9660) in UEFI mode. But, if I take an isohybrid image already containing 'syslinux.efi' (and related files) and I copy the contents onto a FAT partition of a USB drive formatted with a GPT partition table, I could then boot this USB drive in UEFI mode. If, instead of copying the content of the isohybrid image I would use a dd-like method, then the device won't boot in UEFI mode since the (ISO9660) file system is not currently supported by 'syslinux.efi'. I am still of the opinion that the whole FAT "efiboot.img" issue is not about _isohybrid_, but about how GRUB2 does it. For the GRUB2 method, this "efiboot.img" is equivalent to an "El Torito no-emulation" method valid for UEFI. This is the relevant information that concerns the isohybrid tools. (In fact, the UEFI specs are not very clear for common users about the "no-emulation" part. The UEFI specs categorize it as "no-emulation", except that it is not a bootloader as 'isolinux.bin' is (located in the same ISO9660 filesystem) but a superfloppy image, which is closer to a floppy-emulation type (but not exactly the same). In any case, this is more technical than what most users want to know. Users usually want to know which steps to perform and move on.) I said it before: frequently the confusion starts with "guides" making a "salad", by not distinguishing between UEFI specs, GRUB2's methods (and its features) and (buggy) firmware. Then users attempt to follow these "guides" and try to apply the same methods that GRUB2 uses to other bootloaders such as Syslinux. Regarding the characteristics of GRUB2's "efiboot.img", that's about GRUB2, not isohybrid. If a day comes when such image (type) is relevant for Syslinux, the discussion of its characteristics might be relevant then. Regards, Ady.> _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >