> 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.
Hi, some minor nitpicking on Ady's summary:> the real "genisoimage" is not really up to the task for > UEFI-booting.In some distros, genisoimage offers option -e for embedding a FAT filesystem image. (genisoimage is a fork of mkisofs, so "real" is somewhat misleading in respect to history.) For details see: http://www.syslinux.org/wiki/index.php/Isohybrid#UEFI I am author of xorriso and willing to help with ISO 9660 composition, if questions arise.> 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 am not aware that EFI interprets the possibly present partition table of the FAT image in the EFI System Partition. (Regardless whether found by MBR partition table entry, GPT entry, or El Torito boot catalog entry.) EFI from CD/DVD/BD has a soft size limit of 32 MB for its System Partition. That's due to the format of El Torito Boot Catalog which counts the 512-bytes blocks by a 16-bit unsigned integer. But one may attribute size 0 or 1, which means that the System Partition reaches up to the end of the medium. (UEFI 2.4, 12.3.2.1) There is no harm if actually other data are stored after the FAT image. This feature was still on my todo list. I took the occasion to implement it in xorriso. Now looking for testers with a real use case.> 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?In principle this should work. But i saw rumors that attempts with SYSLINUX were not successful. (Hard to say why failure happens with so many parameters involved.) With BIOS, a similar method is used by a Seagate firmware installer ISO image. Most of its software is in an El Torito floppy image with a DR-DOS operating system on it. The ISO 9660 filesytem tree is nearly empty. So this ISO boots from CD into DR-DOS and (nearly ?) all further processing stays in there. ISO 9660 is mainly used to make the El Torito catalog visible to BIOS.> 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) driveThis should be a viable method indeed, if not booting from optical media is desired. The Linux distros rather use a tiny GRUB2 FAT image with embedded configuration (without any dialog of course) from where GRUB2 starts a search for the filesystem with the larger GRUB2 installation which finally offers a user visible menu. Have a nice day :) Thomas
> Hi, > > some minor nitpicking on Ady's summary: > > > the real "genisoimage" is not really up to the task for > > UEFI-booting. > > In some distros, genisoimage offers option -e for embedding > a FAT filesystem image. > (genisoimage is a fork of mkisofs, so "real" is somewhat > misleading in respect to history.) > > For details see: > http://www.syslinux.org/wiki/index.php/Isohybrid#UEFIOK, if the term "real" in the context of that sentence could potentially cause some misunderstanding, then let me clarify what I meant. In the "Linux world", there are currently 3 "popular" command-line tools for these matters: _ "xorriso"; _ "mkisofs", part of "cdrtools" (currently at version 3.01); _ other "thingies" with several forks, patches, iterations, customizations... Some Linux distros use some kind of "redirection" or "renaming", so when a user writes 'genisoimage' with some additional command-line parameters, the actual tool that executes the command might be some other "thingie" (with some patch, or a fork, or whatever). The actual package might even be "mkisofs", but the user writes the command as 'genisoimage'. It all depends on the redirection / renaming / sym-linking / script in each distro. So, someone could ask about the reason(s) I suggested not to use "genisoimage". Well, xorriso and cdrtools (mkisofs) are both currently maintained and both support UEFI-related parameters, but the other "thingies" (with they countless customizations, patches, special cases and whatnot) are not really up-to-date, and in some distros they are not maintained (at all).> > I am author of xorriso and willing to help with ISO 9660 > composition, if questions arise. > > > > 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 am not aware that EFI interprets the possibly present partition > table of the FAT image in the EFI System Partition. > (Regardless whether found by MBR partition table entry, GPT entry, > or El Torito boot catalog entry.) > > EFI from CD/DVD/BD has a soft size limit of 32 MB for its > System Partition. > That's due to the format of El Torito Boot Catalog which > counts the 512-bytes blocks by a 16-bit unsigned integer. > > But one may attribute size 0 or 1, which means that the System > Partition reaches up to the end of the medium. (UEFI 2.4, 12.3.2.1) > There is no harm if actually other data are stored after the FAT > image.Since the topic was about "syslinux.efi", I didn't want to get into those technical details. Although I am not a developer, I was already aware of these potential options you are mentioning. Here is the first catch: real-life firmware (whether BIOS or UEFI, but especially the latter at this point in time) do not always behave as it is expected (by users, or by the standards / specifications, or by none of them). In some (few) occasions, they behave "better" (from the point of view of common users) than the specs pretended, but, more-frequently-than-we-would-like, real-life firmware fails to comply with standards / specs. Whether it is not contemplated in the specs, or because real-life firmware is usually developed and maintained according to some specific bootloader's behavior, my statement is valid: "I'm not sure it would work in real UEFI hardware".> > This feature was still on my todo list. I took the occasion to > implement it in xorriso.And here is the second catch: tools that are actually able to do the thing, and users that would know how exactly to achieve it (and then, how to take advantage of the result). Someone could even think about this one as a "catch-22" case. In any case, the continuous development of xorriso is a good thing; thank you.> Now looking for testers with a real use case. > > > > 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? > > In principle this should work.And real-life UEFI implementations "should" be updated for Linux users too, with support for bootloaders that follow (open) standards, not just according to the most popular one. Well, this "should" is a wishful thinking, not real life.> But i saw rumors that attempts with SYSLINUX were not successful. > (Hard to say why failure happens with so many parameters involved.)Indeed, too much confusion, mixing UEFI specs with what some specific bootloader's behavior with some particular ways to do things, with crappy firmware, with 1600+ pages of "specs", with users' misunderstandings...> > With BIOS, a similar method is used by a Seagate firmware installer > ISO image. Most of its software is in an El Torito floppy image > with a DR-DOS operating system on it. The ISO 9660 filesytem tree > is nearly empty. > So this ISO boots from CD into DR-DOS and (nearly ?) all further > processing stays in there. ISO 9660 is mainly used to make the > El Torito catalog visible to BIOS. > > > > 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 > > This should be a viable method indeed, if not booting from optical > media is desired. > > > The Linux distros rather use a tiny GRUB2 FAT image with embedded > configuration (without any dialog of course) from where GRUB2 > starts a search for the filesystem with the larger GRUB2 > installation which finally offers a user visible menu. > > > Have a nice day :) > > ThomasI still would like more details from Bruno. If indeed "everything" needed to boot the OS is inside the FAT image, then at least 2 issues could be relevant: _ the exact complete characteristics of the FAT image; _ the exact complete command line used to build the ISO image. There are more matters to consider, such as updating the firmware if there is such update available. Feedback about tests with the binaries provided by Gene would be appreciated. If Bruno wants to provide more details, perhaps we could be more useful. Regards, Ady.> > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >
> EFI from CD/DVD/BD has a soft size limit of 32 MB for its > System Partition. > That's due to the format of El Torito Boot Catalog which > counts the 512-bytes blocks by a 16-bit unsigned integer.@Thomas, If you would be so kind, would you please remind me (us)... Is this "32MiB" a limitation related to the UEFI specs in any way? Or is it relevant for BIOS (non-EFI) too? Is this limitation related to the El Torito "emulation" methods/types (01/02/03)? Is this limitation also valid / relevant for the first/default entry in the Boot Catalog? Or is it only relevant for the second+ entries (i.e. the non-default entries in the boot catalog)? Would you please clarify the meaning of your qualifier, "_soft_ size limit"? TIA, Ady.