> Hi, > > Ady wrote: > > 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. > > I don't know whether syslinux.efi can be used for booting > from ISO 9660 via UEFI. Currently there is no example > around which would succeed without GRUB or GRUB2.I don't know how many times I have to express this and in how many different ways: 'syslinux.efi v.6.03 cannot be used for booting from ISO9660 via UEFI. Can 'syslinux.efi' be included in an isohybrid image? Yes, for example as 'EFI/BOOT/BOOTX64.EFI'. Can such isohybrid image be burned to optical media? Yes. Can such optical media boot a BIOS system? Yes, for example if 'isolinux.bin' was used as bootloader when building the image. Additional conditions might be required. Can such optical media boot a UEFI system in UEFI mode? By means of 'syslinux.efi' v.6.03, no, it can not. Can the isohybrid image be dd'ed to a (USB flash) drive? Yes. Let's call it UFD1. Can UFD1 boot a BIOS system? Yes, for example if 'isolinux.bin' was used as bootloader when building the image. Additional conditions might be required, such as adequate isohybrid options. Can UFD1 boot a UEFI system in UEFI mode? By means of 'syslinux.efi' v.6.03, no, it can not. Can the content of the isohybrid image be _copied_ (as opposed to dd'ed) to a (USB flash) drive? Yes. Let's call it UFD2. If UFD2 was previously formatted with a FAT file system (before copying the content of the isohybrid image), can UFD2 boot a BIOS system? Yes; install mbr.bin, set the "boot" flag to the FAT partition and install SYSLINUX to it. Can UFD2 boot a UEFI system in UEFI mode? Yes. Use a GPT partition scheme (instead of the traditional MBR scheme) and a FAT partition. Then _copy_ (as oppose to dd'ing) the content of the isohybrid image to this FAT partition. Having already 'syslinux.efi' included in the original isohybrid image (as 'EFI/BOOT/BOOTX64.EFI' for UEFI x86_64 firmware) means that a FAT partition in a GPT drive can be used as "ESP", with 'syslinux.efi' as default UEFI bootloader of this device for UEFI x86_64 systems. Can the same UFD2 boot either a UEFI system or a BIOS one? Yes, using 'gptmbr.bin' and combining both methods of installation for Syslinux. Are every-and-all (U)EFI systems bootable by a UEFI bootloader located in any "ESP"? No. There are general recommendations, based on experience. But there are also buggy firmware, non-standard firmware, intentional customizations... Is _any_ FAT volume a valid "ESP" in any-and-every case / hardware? No. There are some exceptions (intentional or not), but in time they should be fewer and fewer. Are there filesystems other than FAT that can be "ESP"? According to the UEFI specs, yes. In practice and as a general rule, this possibility should not be blindly trusted. Are there systems in which a FAT volume is not accepted as "ESP"? Yes, but in time they should be fewer and fewer. Please don't ask here for more info about such systems. Are there any additional conditions necessary to succeed in any of the above scenarios? Yes. These are _not_ detailed step-by-step "HowTos", and I currently have no intention to write them either. The Syslinux wiki has more than 100 pages; among others: http://www.syslinux.org/wiki/index.php/Install Are the ISO image building tools (e.g. mksiofs, genisoimage, xorriso...) related to so-called "efiboot.img" files? Yes, in a similar way that they are related to any "El Torito" image. Is the isohybrid tool (in any of its variants) related to so-called "efiboot.img" files? Yes, in a similar way that the isohybrid tool is related to any "El Torito" image. Is the isohybrid tool responsible of generating / building / constructing / filling the content of an "efiboot.img" image? No. How a user creates an "efiboot.img" image file? The user should consult the documentation of the respective bootloader. Syslinux, as of v.6.03, has nothing to do with any so-called "efiboot.img". Once an "efiboot.img" is created, how is it used? The user should consult the documentation of the specific ISO-building tool in use, just as the same documentation is needed for any "El Torito" boot image. Is "efiboot.img" used / needed by every UEFI bootloader? No. There are certain bootloaders for certain OSes that are capable of booting optical media in UEFI mode and are not using so-called "efiboot.img" files. There are also UEFI bootloaders that are _not_ capable of booting ISO9660 file systems in UEFI mode, with or without so-called "efiboot.img" (it doesn't help); 'syslinux.efi' v.6.03 is one of the latter. So, again, is there any use for 'syslinux.efi' v.6.03 in an isohybrid image? Yes. Can 'syslinux.efi' v.6.03 boot some media formatted with ISO9660? Not at this time, no. If a user has an isohybrid image and pretends to boot a UEFI system in UEFI mode with 'syslinux.efi' v.6.03, is dd'ing this isohybrid image on a (USB) drive a useful method? No. Hmm, but dd'ing isohybrid images is so simple...! You have the freedom to waste your time. Are there any kind of images that can be dd'ed to a (USB) drive and that the resulting drive will be capable of using 'syslinux.efi' to boot a UEFI x86_64 system in UEFI mode? Images of a FAT volume in a GPT partitioning scheme already containing 'syslinux.efi' as 'EFI/BOOT/BOOTX64.EFI' (and related files). Should users attempt to build so-called "efiboot.img" files with 'syslinux.efi' v.6.03 in it for ISO(hybrid) images? No, there is no use; 'syslinux.efi' v.6.03 doesn't know what to do with it. What about users putting 'syslinux.efi' v.6.03 inside the "efiboot.img" file? They are free to waste their time. And if users rename 'syslinux.efi' v.6.03 to '/EFI/BOOT/BOOTX64.EFI" inside the "efiboot.img", can it be used? It only occupies space; nothing very useful.> > When describing the UEFI aspects of isohybrid in the wiki, > i left this question open in the hope that somebody would > show a pure SYSLINUX example of UEFI isohybrid. > > The questions of piranna were not the first time that we > had to explain our non-knowledge around ISOLINUX and UEFI. > The wiki needs clarification.For UEFI mode, there is 'syslinux.efi'. As of v.6.03, there are variants of 'syslinux.efi' for UEFI IA32 and for UEFI x86_64. As of v.6.03, there is no such thing as ISOLINUX for UEFI mode. If there are users asking whether there are other things for UEFI in The Syslinux Project as of version 6.03, the answer is: no. As of version 6.03, there is no "memdisk" for UEFI, and many popular c32 modules are currently for BIOS / CSM only, not UEFI. As of version 6.03, 'syslinux.efi' doesn't know yet how to chainload to other EFI binaries. Oh, and before I forget, if there is someone out there asking whether there is "chicken", "beef", or "veggies" for UEFI in The Syslinux Project, the answer is no :). Generally speaking, the documentation includes what The Syslinux Project does. Sadly, some documentation might be outdated, or even incorrect in some case (although some few of us try to reduce such instances). Adding documentation about what The Syslinux Project cannot do would be nice, but realistically... Permanently maintaining such kind of documentation in a coherent way and in a timely manner could potentially produce more misunderstandings too. At some point, some responsibility must fall onto users' hands. The Syslinux Project cannot overcome by itself the amount of misinformation about Syslinux, booting, BIOS, UEFI and other bootloaders in general; simply there are not enough resources.> > > > I am still of the opinion that the whole FAT "efiboot.img" issue is not > > about _isohybrid_, but about how GRUB2 does it. > > It is about what UEFI expects (without an UEFI boot manager > like rEFInd involved). It wants an UEFI image, i.e. a *.efi > file. Its own means of finding it are the EFI System > Partitions of the devices, the NVRAM variables (e.g. > manipulated by efibootmgr(8)), and the fallback paths > (e.g. /efi/boot/bootx64.efi).Since GRUB2 is currently using "efiboot.img" files, IMHO additional documentation about such images could/should be originated in/by GRUB2.> > > > In fact, the UEFI specs are not very clear for common users about the > > "no-emulation" part > > You mean "no emulation" in the sense of El Torito ? > (As opposed to "1.2 MB diskette", "1.44 MB diskette", > "2.88 MB diskette", and "hard disk drive".) > > This will not be noted by EFI from USB stick. Only with > EFI from CD-ROM (and DVD or BD).The "efiboot.img" file is the (equivalent of) "El Torito" image for UEFI used by GRUB2, so it is also relevant for a USB stick dd'ed with an adequately-built isohybrid image.> I assume most EFI implementations ignore the Boot Media > Type fields in the El Torito boot catalog and only look > for Platform ID 0xef. > > In UEFI specs, El Torito just serves as substitute for > a partition table. > > > > a superfloppy image, > > It's more like a twenty years old hard disk. > UEFI 2.6, 12.3 "File System Format": > "EFI encompasses the use of FAT32 for a system partition > [...] The definition of the EFI file system will be > maintained by specification and will not evolve over > time to deal with errata [...]"No, "efiboot.img" has no partition table inside it. It is a FAT volume. I called it a "superfloppy" because of its total size, usually bigger than a 2880KiB. (OT: "El Torito floppy emulation" accepts bigger sizes than 2880KiB, but that's a completely different matter and has nothing to do with this email thread.)> > When used with El Torito, the image should not be larger > than 32 MiB. That's because the Sector Count fields in > the boot catalog have only 16 bits. > > > > 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. > > Well, since all traditional users of ISOLINUX isohybrid enhance > their ISO production by a FAT image, modules, and configuration > from GRUB or GRUB2, in order to make use of isohybrid option --uefi > ... i would say it is relevant.See my prior comments in this same email.> > Anybody show me a pure SYSLINUX isohybrid ISO that boots via EFI > and i will be able to dissect it and hopefully derive knowledge > for the wiki.See my prior comments in this same email.> > > Have a nice day :) > > Thomas >Now I shall put UEFI matters aside for some time 8-P. Where are those nice ol' 8086 without HDD when one needs them :). Regards, Ady.> _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >
On 06/04/2015 20:57, Ady via Syslinux wrote:> >> Hi, >> >> Ady wrote: >>> 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. >> >> I don't know whether syslinux.efi can be used for booting >> from ISO 9660 via UEFI. Currently there is no example >> around which would succeed without GRUB or GRUB2. > > I don't know how many times I have to express this and in how many > different ways: 'syslinux.efi v.6.03 cannot be used for booting from > ISO9660 via UEFI. > > Can 'syslinux.efi' be included in an isohybrid image? > Yes, for example as 'EFI/BOOT/BOOTX64.EFI'. > > Can such isohybrid image be burned to optical media? > Yes. > > Can such optical media boot a BIOS system? > Yes, for example if 'isolinux.bin' was used as bootloader when > building the image. Additional conditions might be required. > > Can such optical media boot a UEFI system in UEFI mode? > By means of 'syslinux.efi' v.6.03, no, it can not. > > Can the isohybrid image be dd'ed to a (USB flash) drive? > Yes. Let's call it UFD1. > > Can UFD1 boot a BIOS system? > Yes, for example if 'isolinux.bin' was used as bootloader when > building the image. Additional conditions might be required, such as > adequate isohybrid options. > > Can UFD1 boot a UEFI system in UEFI mode? > By means of 'syslinux.efi' v.6.03, no, it can not. > > Can the content of the isohybrid image be _copied_ (as opposed to > dd'ed) to a (USB flash) drive? > Yes. Let's call it UFD2. > > If UFD2 was previously formatted with a FAT file system (before copying > the content of the isohybrid image), can UFD2 boot a BIOS system? > Yes; install mbr.bin, set the "boot" flag to the FAT partition and > install SYSLINUX to it. > > Can UFD2 boot a UEFI system in UEFI mode? > Yes. Use a GPT partition scheme (instead of the traditional MBR > scheme) and a FAT partition. Then _copy_ (as oppose to dd'ing) the > content of the isohybrid image to this FAT partition. Having already > 'syslinux.efi' included in the original isohybrid image (as > 'EFI/BOOT/BOOTX64.EFI' for UEFI x86_64 firmware) means that a FAT > partition in a GPT drive can be used as "ESP", with 'syslinux.efi' as > default UEFI bootloader of this device for UEFI x86_64 systems. > > Can the same UFD2 boot either a UEFI system or a BIOS one? > Yes, using 'gptmbr.bin' and combining both methods of installation for > Syslinux. > > Are every-and-all (U)EFI systems bootable by a UEFI bootloader located > in any "ESP"? > No. There are general recommendations, based on experience. But there > are also buggy firmware, non-standard firmware, intentional > customizations... > > Is _any_ FAT volume a valid "ESP" in any-and-every case / hardware? > No. There are some exceptions (intentional or not), but in time they > should be fewer and fewer. > > Are there filesystems other than FAT that can be "ESP"? > According to the UEFI specs, yes. In practice and as a general rule, > this possibility should not be blindly trusted. > > Are there systems in which a FAT volume is not accepted as "ESP"? > Yes, but in time they should be fewer and fewer. Please don't ask here > for more info about such systems. > > Are there any additional conditions necessary to succeed in any of the > above scenarios? > Yes. These are _not_ detailed step-by-step "HowTos", and I currently > have no intention to write them either. The Syslinux wiki has more than > 100 pages; among others: > http://www.syslinux.org/wiki/index.php/Install > > Are the ISO image building tools (e.g. mksiofs, genisoimage, > xorriso...) related to so-called "efiboot.img" files? > Yes, in a similar way that they are related to any "El Torito" image. > > Is the isohybrid tool (in any of its variants) related to so-called > "efiboot.img" files? > Yes, in a similar way that the isohybrid tool is related to any "El > Torito" image. > > Is the isohybrid tool responsible of generating / building / > constructing / filling the content of an "efiboot.img" image? > No. > > How a user creates an "efiboot.img" image file? > The user should consult the documentation of the respective > bootloader. Syslinux, as of v.6.03, has nothing to do with any > so-called "efiboot.img". > > Once an "efiboot.img" is created, how is it used? > The user should consult the documentation of the specific ISO-building > tool in use, just as the same documentation is needed for any "El > Torito" boot image. > > Is "efiboot.img" used / needed by every UEFI bootloader? > No. There are certain bootloaders for certain OSes that are capable of > booting optical media in UEFI mode and are not using so-called > "efiboot.img" files. There are also UEFI bootloaders that are _not_ > capable of booting ISO9660 file systems in UEFI mode, with or without > so-called "efiboot.img" (it doesn't help); 'syslinux.efi' v.6.03 is one > of the latter. > > > So, again, is there any use for 'syslinux.efi' v.6.03 in an isohybrid > image? > Yes. > > Can 'syslinux.efi' v.6.03 boot some media formatted with ISO9660? > Not at this time, no. > > If a user has an isohybrid image and pretends to boot a UEFI system in > UEFI mode with 'syslinux.efi' v.6.03, is dd'ing this isohybrid image on > a (USB) drive a useful method? > No. > > Hmm, but dd'ing isohybrid images is so simple...! > You have the freedom to waste your time. > > Are there any kind of images that can be dd'ed to a (USB) drive and > that the resulting drive will be capable of using 'syslinux.efi' to > boot a UEFI x86_64 system in UEFI mode? > Images of a FAT volume in a GPT partitioning scheme already containing > 'syslinux.efi' as 'EFI/BOOT/BOOTX64.EFI' (and related files). > > Should users attempt to build so-called "efiboot.img" files with > 'syslinux.efi' v.6.03 in it for ISO(hybrid) images? > No, there is no use; 'syslinux.efi' v.6.03 doesn't know what to do > with it. > > What about users putting 'syslinux.efi' v.6.03 inside the "efiboot.img" > file? > They are free to waste their time. > > And if users rename 'syslinux.efi' v.6.03 to '/EFI/BOOT/BOOTX64.EFI" > inside the "efiboot.img", can it be used? > It only occupies space; nothing very useful. > > >> >> When describing the UEFI aspects of isohybrid in the wiki, >> i left this question open in the hope that somebody would >> show a pure SYSLINUX example of UEFI isohybrid. >> >> The questions of piranna were not the first time that we >> had to explain our non-knowledge around ISOLINUX and UEFI. >> The wiki needs clarification. > > > For UEFI mode, there is 'syslinux.efi'. As of v.6.03, there are > variants of 'syslinux.efi' for UEFI IA32 and for UEFI x86_64. > > As of v.6.03, there is no such thing as ISOLINUX for UEFI mode. > > If there are users asking whether there are other things for UEFI in > The Syslinux Project as of version 6.03, the answer is: no. > > As of version 6.03, there is no "memdisk" for UEFI, and many popular > c32 modules are currently for BIOS / CSM only, not UEFI. > > As of version 6.03, 'syslinux.efi' doesn't know yet how to chainload to > other EFI binaries. > > Oh, and before I forget, if there is someone out there asking whether > there is "chicken", "beef", or "veggies" for UEFI in The Syslinux > Project, the answer is no :).Hi Just including these statements (Q & A) as is in the Syslinux wiki would help a lot newbies like me. That's exactly the kind of information I'd expect to find in a FAQ. Not all users follow this list or able to remember of find what was said in it time ago. Thanks and best regards, Diider
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. 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. 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). 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. Have a nice day :) Thomas
> 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 canunderstand 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 >
Hello, Ady via Syslinux said on Mon, Apr 06, 2015 at 09:57:02PM +0300:>Can 'syslinux.efi' v.6.03 boot some media formatted with ISO9660? > Not at this time, no.It took me quite some time to find that :-( Google didn't really help. I'd like to get a bit more details on this issue: 1/ Using syslinux.efi for PXE booting of a UEFI server is working for me. 2/ Using syslinux.efi for booting from the local HDD of a UEFI server is working for me. 3/ Using syslinux.efi in a FAT32 image (similar to the previous 2 confs) stored on a iso9660 media by genisoimage and its -eltorito-alt-boot -efi-boot $imagefile -no-emul-boot option doesn't work. I get a red screen with debug info (attached). However, I'm not trying to access anything outside of the FAT32 FS. I thought it wouldn't be related to iso9660 in that use case. (I use wirtual media method mounted via iLO URL CD feature if that matters) So my question is (and sorry I started last week on that issue, read lots of wiki page without finding an answer, but I may have missed it and welcome links): is there a way, using syslinux.efi to embed it on an ISO iso9660 formatted image in its boot part and have a successful boot of my machine ? I read that iso9660 support could be added to syslinux.efi for that, but I really have no clue where to start from, and even before trying what may be way outside of my capabilities, I'd alredy like to know if that what is really needed. Context: I do that in order to add UEFI support to the MondoRescue Disaster Recovery project I'm leading (http://www.mondorescue.org). I used grub 0.99 for the RHEL6 support, but don't want to mess with that especially as I already have procedures to generate syslinux/isolinux/pxelinux conf files in the tool. Thanks in advance for any hint Bruno. -- Open Source Profession, Linux Community Lead WW http://opensource.hp.com HP EMEA EG Open Source Technology Strategist http://hpintelco.net FLOSS projects: http://mondorescue.org http://project-builder.org Musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -------------- next part -------------- A non-text attachment was scrubbed... Name: syslinux.efi-1.png Type: image/png Size: 20561 bytes Desc: not available URL: <http://www.zytor.com/pipermail/syslinux/attachments/20151022/d24cb300/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: syslinux.efi-2.png Type: image/png Size: 19008 bytes Desc: not available URL: <http://www.zytor.com/pipermail/syslinux/attachments/20151022/d24cb300/attachment-0001.png>
On Thu, Oct 22, 2015 at 1:56 PM, Bruno Cornec via Syslinux <syslinux at zytor.com> wrote:> 3/ Using syslinux.efi in a FAT32 image (similar to the previous 2 > confs) stored on a iso9660 media by genisoimage and its > -eltorito-alt-boot -efi-boot $imagefile -no-emul-boot option doesn't > work. I get a red screen with debug info (attached). However, I'm not > trying to access anything outside of the FAT32 FS. I thought it > wouldn't be related to iso9660 in that use case. (I use wirtual media > method mounted via iLO URL CD feature if that matters)I'd suggest using the latest general-purpose test binaries I've published. https://sites.google.com/site/genecsyslinux/sl604p0g18-x64.tgz?attredirects=0&d=1 -- -Gene
> Hello, > > Ady via Syslinux said on Mon, Apr 06, 2015 at 09:57:02PM +0300: > >Can 'syslinux.efi' v.6.03 boot some media formatted with ISO9660? > > Not at this time, no. > > It took me quite some time to find that :-( Google didn't really help. > > I'd like to get a bit more details on this issue: > > 1/ Using syslinux.efi for PXE booting of a UEFI server is working for > me. > 2/ Using syslinux.efi for booting from the local HDD of a UEFI server is > working for me. > > 3/ Using syslinux.efi in a FAT32 image (similar to the previous 2 > confs) stored on a iso9660 media by genisoimage and its > -eltorito-alt-boot -efi-boot $imagefile -no-emul-boot option doesn't > work. I get a red screen with debug info (attached). However, I'm not > trying to access anything outside of the FAT32 FS. I thought it > wouldn't be related to iso9660 in that use case. (I use wirtual media > method mounted via iLO URL CD feature if that matters) > > So my question is (and sorry I started last week on that issue, read > lots of wiki page without finding an answer, but I may have missed it > and welcome links): > > is there a way, using syslinux.efi to embed it on an ISO iso9660 > formatted image in its boot part and have a successful boot of my > machine ? > I read that iso9660 support could be added to syslinux.efi for that, but > I really have no clue where to start from, and even before trying what > may be way outside of my capabilities, I'd alredy like to know if that > what is really needed. > > Context: I do that in order to add UEFI support to the MondoRescue > Disaster Recovery project I'm leading (http://www.mondorescue.org). I > used grub 0.99 for the RHEL6 support, but don't want to mess with that > especially as I already have procedures to generate > syslinux/isolinux/pxelinux conf files in the tool. > > Thanks in advance for any hint > Bruno. > -- > Open Source Profession, Linux Community Lead WW http://opensource.hp.com > HP EMEA EG Open Source Technology Strategist http://hpintelco.net > FLOSS projects: http://mondorescue.org http://project-builder.org > Musique ancienne? http://www.musique-ancienne.org http://www.medieval.org >I apologize in advance for the length of this email. I hope someone would care enough to actually read it. There are several issues to consider. The first one, not directly related to any bootloader in particular, is that the real "genisoimage" is not really up to the task for UEFI-booting. You either need "mkisofs" (from "cdrtools", and even better would be to use the latest version available, v.3.01 at the moment), or xorriso (which has a _slightly_ different approach in certain regards when comparing to mkisofs, such as the "isohybrid" matters, or the command line syntax / parameters related to UEFI-booting). Now, regarding the file system. Using a FAT fs is commonly known to be supported by current UEFI firmware. As first thought, having the "adequate" 'syslinux.efi' file and the corresponding core module, "ldlinux.e*", in a FAT fs would _seem_ enough. During "the old days", optical media would boot using a FAT image (using SYSLINUX or some other storage bootloader using "EL Torito emulation", not ISOLINUX). Then an OS-specific "driver" would allow access to the rest of the optical media (the ISO9660 file system); emphasize on "OS-specific", meaning that such access was achieved _after_ the OS was up and running. There were/are other methods available, but let's focus on this one for a moment. The firmware ("BIOS" at the time) still had to be able to recognize the available optical media as potential boot device, and the correct booting steps had to be executed. If, for instance, the boot sector of the FAT (usually, floppy) image was not adequate, the booting steps would had eventually failed, just as with any real storage media. UEFI firmware does not use the FAT boot sector(s). UEFI says, roughly, "hey, here is a file system volume that I recognize, I can understand / read (at least certain types of) files in this volume; let's see if I can find a certain kind of file that I like and then pass the control to it". Let's assume you use an adequate tool (not "genisoimage") with adequate command line parameters so to build an adequate UEFI-bootable ISO image and that you correctly burn such image to optical media (or, with the ISO image you boot a UEFI VM as virtual optical media). Let's also assume that you boot in UEFI mode, and that both "syslinux.efi" and the corresponding "ldlinux.e*" core module load. This latter assumption is not trivial, as the FAT fs is not "real", but an image located on another (ISO9660) volume. Would 'syslinux.efi' be able to do whatever (and everything) it needs to do under these conditions? Could any kernel be _completely and successfully_ booted under these conditions? Rhetorical question: And then what? Syslinux would have access to the FAT volume (usually less than 32MiB), but it would not be able to access the whole ISO9660 file system (or, in other words, the rest of the optical media, outside the FAT image). Remember, as of version 6.03, Syslinux has no access to other file system volumes other than the one it booted from. Alternatively, instead of using a "floppy-like" ("super-floppy", "partition-less") FAT image, you "could" try a "HDD-like" image, with GPT (somewhat equivalent to the "El Torito HDD-emulation" method under BIOS). I'm not sure it would work in real UEFI hardware, and, more importantly... Would anyone expect a UEFI-based hardware to boot from an optical device in which the booting optical media is almost-all a FAT32 HDD image? IMO, it would make more sense to just distribute a (compressed) FAT image directly (no need for ISO9660) and use other booting methods, such as a USB (flash) drive (which 'syslinux.efi' can boot from). There are methods to develop file system "UEFI applications", a way to add support to additional specific file systems. If a UEFI firmware understands FAT (as it is known to happen in current UEFI-based hardware), and/or if there was some way to add support for ISO9660 (at each booting occasion), and if "syslinux.efi" would understand ISO9660 (in a similar way as files can be read after booting with ISOLINUX under BIOS, generally speaking), and if the Syslinux family of boot loaders would be able to have access to other volumes (other than the one it booted from), _then_ we might probably be able to use "syslinux.efi" to boot optical media in a _meaningful manner_. We are far from such conditions, as of Syslinux 6.03. BTW, "multifs" is on its way (at some point in the future), but, strictly speaking there is not real "planning", and certainly no ETA. Please avoid going off-topic. Regards, Ady.