> Hi, > > Ady: > > _ Wiki should use more user-friendly language and "less deep" > > technical information. > > I tried to stay at the surface of isohybrid. > (Didier already asked for more depth about expert options.)My interpretation of Didier's questions is less depth and more user-friendly practical commands for end-users. Our points of view about what is desired / necessary / adequate for this isohybrid page seem to have some in-common areas, and some that not.> > > > _ In the Syslinux wiki, "PC-BIOS" should rather be called plain > > "BIOS". > > I understand there are other "BIOS" for other hardware. > But ok. Let's use the term BIOS. > > > > _ Specific ISO-building tools should not be part of the generic > > explanation, but rather a separate section, such as "Examples". > > I give the examples to make clear what is meant in the > general statements. > > The three programs mentioned are those which users will encounter > on free operating systems. I understand they all are available > under Cygwin, too.Mentioning them and posting examples should be OK, but the order and sections are relevant for common users/readers. For instance, if a common user reads a section about a general concept, then introducing commands of specific tools (even with the intention of clarity) could make the reader (mis)understand that such tool or such commands are part of the general concept. This can be even more confusing when using commands for 3 alternative tools. Interleaving different types of information (such as general concept with specific commands) _could_ be still done by using careful wording. Considering common users as main target, I believe a separate section in the same wiki page to be more adequate. Regarding current versions of the 3 tools built with cygwin, I only know of mkisofs.> > > > _ Specific details (e.g. about the usage of the respective > > ISO-building tools) should be searched in the respective > > documentation for each tool, not in the Syslinux wiki. > > It's a standard complaint that this documentation is either too > fat or too sparse.One of the reasons for my comment is that some users contact Syslinux (through mailing list, irc) about "anything" related to booting, or "blame" Syslinux (for example in forums) for failure to boot, even in those cases where Syslinux is not the adequate place or the source of their problems. Another reason is that the Syslinux wiki should be helpful to common users, and not a University paper (please understand this as a generic sentence and not for this particular page or discussion). If a common user can understand the basic concept and the basic method, then we are on the right track. For instance, should the _isohybrid_ wiki page in Syslinux include details about ISO9660 or FAT or MBR or partition tables? Or about the MBR/GPT differences? Or about the backup in a GPT layout? Perhaps mentioning the possibility that their original ISO images might be slightly bigger after using the isohybrid command is relevant *for common users*, while mentioning the technical background for such increment is not relevant (and might even be a "con") in the same wiki page for the main target reader?> > Especially problematic is the fact that the home page of > cdrtools has vanished and the -e-capable version of genisoimage > is not the vanilla version from cdrkit.Cdrtools (cdrecord) has been recently (partially) moved, to: http://sourceforge.net/projects/cdrtools/?source=navbar http://cdrecord.org/ Note 1: Originally, this move was because of Berlios' changes. Note 2: Unfortunately the internal links were not adequately moved, and some information (e.g. mailing list) has been apparently lost.> > The examples given are derived from the basic mkisofs example on > http://www.syslinux.org/wiki/index.php/ISOLINUX#How_Can_I_Make_a_Bootable_CD_With_ISOLINUX.3F > > > > _ It should be clear for a common reader that any commands involving > > ISO-building tools are just very basic examples > > That's the nature of examples in documentation. > They give a starting point for detail study and development. > > > > _ Mentioning paths for specific distros should be avoided if > > possible. > > I count them as hands-on examples....Not if they are placed in the middle of a "general concept" section of a wiki page. If it doesn't provide relevant info for common readers to make their first steps or to solve a basic doubt, specific paths are going to interrupt the natural reading flow, specially for users of OS with different directory-tree structures.> > > > _ When a command or tool works only under certain OS or OS-type (e.g. > > Linux), this fact should be mentioned. > > Throughout the wiki there is a lack of non-Linux info. > I personally cannot fill this gap, because i lack experience > with Apple and Microsoft. > > > > When > > information is too-technical, or the wording sounds too-technical, > > most users won't even read it. > > I only mentioned what i deem indispensible to understand > the purpose and the variations of isohybrid. > If you see particular statements which are surplus under this > aspect, then we can discuss and eventually throw them out.IMHO (not a strict list): _ basic general concept, relevant for common user (one paragraph, something about "image bootable in optical media and USB drives"); _ general "pros/cons" relevant for common users: the USB drive is overwritten, with one non-writable filesystem, part of the USB drive is not being used/seen; _ different variants exist, which ones are those variants; _ requirements and limitations: matching version with ISOLINUX in the ISO image, Perl OS-independent, based on C is OS (Linux) -dependent, possibility to produce images bootable in UEFI systems,...; _ respective command options for isohybrid variants, specially those included in Syslinux, optionally listing or mentioning or linking to the relevant options available in those variants not included in Syslinux. _ basic examples; _ resources, see also, more info... Again, this is not a thorough strict list, and it might even be technically inaccurate at certain levels; I am thinking about common users.> > > > _ in the "mbr" page (where other alternative *.bin files are already > > mentioned); or, > > There is an MBR page ? Where ? I'd like to link to it.http://www.syslinux.org/wiki/index.php/Mbr> > > > _ The firmware "target(s)" can be different than the one used by the > > host where the ISOLINUX and/or isohybrid image is being built. > > Multiple simultaneous firmware targets are allowed (although this > > possibility depends on the variant and version of the isohybrid > > program too). > > Urm. Now you lost me. What exactly is meant with "firmware target" ? > BIOS, UEFI, MAC ?A user could be building an image so to be bootable in UEFI systems (too), but he is building such image in a BIOS system. A user could be building an image so to be bootable in x86 systems (too), but he is building such image in a x86_64 system. This might sound trivial, but for some common users it is not. For example, a user might think "-u" should be used when the system where the isohybrid command is being executed is a UEFI one, even if he only wants to build an image to be bootable only in BIOS. This specific example is probably not realistic, but my focus is on the difference between "the system where the isohybrid command is being executed" and "the target system(s) that should be bootable with the resulting image/media". My point is, the options ("-u", "-m", "-b"...) are for the "target" system(s), and (at least some) combinations are allowed.> > > > _ Eventually "isohybrid" should be a separate page in the wiki > > Could be easily done. Currently it is just exposed for discussion. > > > > _ Relevant items for common users: > > _ command options supported by each isohybrid variant; > > I avoided to show options. The only one is clearly attributed to > utils/isohybrid.c. > > > > _ if the version of the isohybrid program should match the version > > of ISOLINUX (perhaps depending on isohybrid variant, or version that > > includes a new feature, or ISO-building tool used, or...), this fact > > should be clearly mentioned. > > I wrote: > "Both programs contain MBR code which has to match the version of > the ISOLINUX file isolinux.bin. So always use the program from the > same SYSLINUX installation which provided this file for the ISO 9660 > production." > > Better wording would be welcome. > > > > _ if different iso*.bin files are to be used for different needs, > > then each case should be clear for the common user. > > It is not even clear to the uncommon wiki writer. > So i cowardly staid with defaults. > > > > _ What to do with the resulting ISO image; > > Yeah. Putting an image onto USB stick is not easy to explain. > (Best is to have read S.R. Bourne's "The Unix System".) > > On MS-Windows i would be totally helpless.As I mentioned before, the generic explanation should be adequate for the isohybrid page in the Syslinux wiki. There are too many tools with their own pros and cons, and each distro has its own recommendations / documentation. Windows users, just as Linux users, can use a web search engine. There are enough articles about different methods and tools. Some of them are provided by Linux distros for Windows users, and several others are developed independently (more than one hosted in sf.net). There are also "dd for Windows" variants, "image writers" and "multiboot GUI" tools. That's enough.> > > > _ xorriso builds the ISO image, and it can (optionally and) > > simultaneously make it isohybrid too. This is an _alternative_ > > method. > > Stated by "The result needs no further treatment by isohybrid tools." > > > > _ The different _alternatives_ should be clear to a common user, > > specially to avoid confusion with "serial-like" steps. > > I hoped to make clear that the user should run one isohybrid > command, or produce the ISO with isohybrid on the first hand.As one of Didier's questions suggests, the _alternative_ methods seem to be not clear enough. This is another reason to write "see [[#Examples]]" or alike throughout the more generic sections, and then use a separate section for the alternative tools, with steps for each alternative.> > > > _ Yet, the steps should be "generic", as opposed to getting into the > > details > > I would try to do this if i could. > Examples need to be tangible. So they expose details. > > Do you have proposals how to avoid this dilemma ? > > > > This wiki page should focus on the isohybrid variants and their > > available options / differences. > > I showed three of the variants: isohybrid.pl, isohybrid.c, xorriso. > The other two are not clear enough to me.Do you mean from Slitaz?> > > > _ BTW, mkisofs supports building ISO images for EFI, but the specific > > arguments are different than those used by xorriso. > > It would be helpful to know that option.Example with relevant mkisofs options: -no-emul-boot -boot-load-size 4 -boot-info-table \ -b isolinux/isolinux.bin \ -c isolinux/isolinux.boot \ -eltorito-alt-boot -no-emul-boot -eltorito-platform 0xEF \ -eltorito-boot isolinux/efiboot.img \ Note 1: The "isolinux/" path is just for this example. Note 2: The "efiboot.img" file name is just for this example. Note 3: "-eltorito-platform 0xEF" is equivalent to "-eltorito-platform efi". If I am not mistaken, this is the equivalent to xorriso's "-e". Note 4: Part of the options are new since some 3.01a(lpha) version. Note 5: Although _I am not sure_, I think other possibilities could be: -eltorito-boot EFI/BOOT/BOOTX64.IMG -eltorito-boot EFI/BOOT/BOOTX64.EFI instead of the above "-eltorito-boot isolinux/efiboot.img" but that's for someone (else) to test and confirm.> > > Have a nice day :) > > Thomas > >Thank you, Ady.
> > When > > information is too-technical, or the wording sounds too-technical, > > most users won't even read it.Although a "list lurker", I'd like to make a brief comment (stating the obvious). Documentation will have different audiences, ranging from [sometimes not-clueful] end-users to people trying to make distros bootable under different conditions, to those who may want to learn enough background to contribute to the project in some way. Each will complain differently when they use the Wiki, not only because the information they're looking for is different, but because the background each brings with them is different. I believe that reorganization of the documentation keeping this in mind would be the "best" solution, rather than debating what to leave in or cut out. There have been multiple times I've been interested in a piece of software and wanted to find out its history so I could orient myself, and some "helpful" soul had decided that all the old stuff was unnecessary and deleted it. Conversations with long-time developers (when I could find any) were required to learn things. It wastes time and is painful for everyone. (No, I'm not volunteering -- I knew you were gonna ask. I don't know enough to be able to make good decisions, someone would have to review and clean up after me.) Please don't delete "old" or "useless" stuff. It *will* be useful to *someone*. Also, If I'm trying to learn more about booting, it makes sense to dig into this project. If you delete technical information that I need to know, could I Google for it? Sure -- but it would be a lot easier if the information were already here. It's a fine line between deciding what information should be included in the docs here and what should be searched for. But remember that searching isn't free in cost of the user's time. If you delete information, at least insert a link to the information elsewhere on the web (even knowing the link might go stale or missing). As far as marking software frozen, I would suggest that "frozen" is a value judgement: if I want to work on it, then it's not frozen anymore, right? If it's felt that it's deprecated or superseded for some reason, the software should be annotated as such, together with the reason(s) why and what would be required to make it up-to-date (if possible). If I'm then attracted to use it or (God forbid!) work on it :-), then I would know what I'm getting into and be able to intelligently decide if it's worth it and how I might be hurt in the process. Sorry to interrupt your conversation. "Now back to our regularly scheduled programming". Thanks for reading.
Hi,> For instance, if a common user reads a section about a general > concept, then introducing commands of specific tools (even with the > intention of clarity) could make the reader (mis)understand that such > tool or such commands are part of the general concept.The first example with "xorriso ... -isohybrid-mbr" serves the purpose to explain how the isohybrid feature can already by applied at ISO generation time. The second one with "genisoimage ... -e" is a necessary precondition for the run of isohybrid --uefi.> Regarding current versions of the 3 tools built with cygwin, I only > know of mkisofs.I know from user feedback that GNU xorriso gets built on cygwin without problems.> For instance, should the _isohybrid_ > wiki page in Syslinux include details about ISO9660 or FAT or MBR or > partition tables?I'd say no. But it has to be mentioned that isohybrid is about adding an MBR. It is necessary to know that for --uefi the ISO image has to contain an EFI boot image, which is supposed to be a FAT filesystem. It should also be mentioned that the boot path for UEFI is not only El Torito and GPT but also a partition entry in MBR. That's just the immediate interfaces which isohybrid needs as input or provides as output.> http://cdrecord.org/Ah yes.> > If you see particular statements which are surplus under this > > aspect, then we can discuss and eventually throw them out.> IMHO (not a strict list):Urm. That is a list of new topics, not of surplus statements in my proposals.> _ basic general concept, relevant for common user (one paragraph, > something about "image bootable in optical media and USB drives");I thought to have provided this in my proposal. A motivation in the first two statements and then a quick tour with several key terms and concepts.> _ general "pros/cons" relevant for common users: the USB drive is > overwritten, with one non-writable filesystem, part of the USB drive > is not being used/seen;Yes. The whole discussion is still missing about suitable storage media and how to put the image onto them.> _ different variants exist, which ones are those variants;Three of them are presented in the BIOS paragraph. One of them is not mentioned in UEFI because not capable of it.> _ requirements and limitations: matching version with ISOLINUX in the > ISO image, Perl OS-independent, based on C is OS (Linux) -dependent, > possibility to produce images bootable in UEFI systems,...;This is mentioned for the both SYSLINUX tools. See bullet list. xorriso dependencies and installation is not really in the scope of the wiki. (I'd blatantly advertise GNU xorriso if i am invited to do.)> _ respective command options for isohybrid variants, specially those > included in Syslinux,That would be the job of a man page. One could start with the quickly-made one from Ubuntu http://manpages.ubuntu.com/manpages/natty/man1/isohybrid.1.html With -h or -s we get to the same undecidable discussions about cylinder size which we had a while ago. We did not really make progress with getting this well documented. -e , -t, -i are MBR specific. -o is a bit questionable, as a non-zero value will normally make the partition unmountable. --forcehd0, --ctrlhd0, --partok choose the built-in MBR template. They all need exploration and lots of background information.> _ basic examples;I claim that isohybrid output.iso isohybrid --uefi output.iso are basic.> _ resources, see also, more info...I take proposals.> http://www.syslinux.org/wiki/index.php/MbrAhum. This this suggests that "hd0" in "--forcehd0" and "--ctrlhd0" are about BIOS disk 0x80 and suffixes "_f" and "_c". "--partok" would then select a flavour of "altmbr.bin" rather than one of "mbr.bin".>From section "Write" one could derive instructions about howto put the image onto an USB stick by help of Linux. Probably the article should have a short introduction into the concept of MBR. I put a link to it into my proposal (if the captcha thing lets me).> > > _ The firmware "target(s)" can be different than the one used by the > > > host where the ISOLINUX and/or isohybrid image is being built. > > Now you lost me. > A user could be building an image so to be bootable in UEFI systems > (too), but he is building such image in a BIOS system.Do we really have to explain that the firmware is not of importance after the operating system has booted ?> My point is, the options ("-u", "-m", "-b"...) are for the "target" > system(s), and (at least some) combinations are allowed.This is indeed worth to be mentioned. But it is not really specific to isohybrid, but rather to the question what interfaces and early stage software has to be offered to the intended boot firmware. More or less the overall topic of SYSLINUX et.al.> As one of Didier's questions suggests, the _alternative_ methods seem > to be not clear enough.I am pondering about a translation table from isohybrid options to isohdp[fp]x*.bin and the terminology in the Mbr article. (Three terminologies for the same thing. Sometimes, choice is bad.)> > I showed three of the variants: isohybrid.pl, isohybrid.c, xorriso. > > The other two are not clear enough to me.> Do you mean from Slitaz?Yep. The .sh script and the .c program which both seem to perform isohybrid for BIOS. But i did not analyze them in detail.> -eltorito-platform 0xEF \Now added to the UEFI section. (More example code, of course. Maybe it should be presented without <pre>...</pre>.) Have a nice day :) Thomas
Hi,> Each will complain differently when they use the WikiYes. I am regularly biting the table when trying to find answers in documentation.> No, I'm not volunteering -- I knew you were gonna ask.But precognition would be a great qualification for writing understandable docs.> If you delete technical information that I need to know, > could I Google for it? Sure -- but it would be a lot easier if the > information were already here.At least i try to provide search words for googling. Have a nice day :) Thomas
Hi, Ady:> -eltorito-boot EFI/BOOT/BOOTX64.EFIThis is most probably wrong, as this seems to be the prescribed name for a file inside the EFI-understandable filesystem. This filesystem would not be the ISO 9660 but rather the FAT image file which serves as EFI boot image.> -eltorito-boot EFI/BOOT/BOOTX64.IMGThis might be better. From where did you learn that name ? I still did not find information about how to create the FAT image. My best guess for now is to simply install enough SYSLINUX in a FAT filesystem image, so that it can chainload isolinux.bin from the ISO filesystem. https://wiki.archlinux.org/index.php/Syslinux#Installation_2 But that's just a speculation. Maybe somebody should peek into Fedora Live CD: # mount -o loop Fedora-Live-Desktop-x86_64-20-1.iso /mnt/iso # mount -o loop /mnt/iso/isolinux/efiboot.img /mnt/fat $ find /mnt/fat/efi/boot /mnt/fat/efi/boot /mnt/fat/efi/boot/fonts /mnt/fat/efi/boot/fonts/unicode.pf2 /mnt/fat/efi/boot/grub.cfg /mnt/fat/efi/boot/bootx64.efi /mnt/fat/efi/boot/grubx64.efi Hrmpf. Obviously not SYSLINUX equipment in there. Anybody can shed light on that issue ? Have a nice day :) Thomas
> Hi, > > > For instance, if a common user reads a section about a general > > concept, then introducing commands of specific tools (even with the > > intention of clarity) could make the reader (mis)understand that such > > tool or such commands are part of the general concept. > > The first example with "xorriso ... -isohybrid-mbr" serves the > purpose to explain how the isohybrid feature can already > by applied at ISO generation time. > > The second one with "genisoimage ... -e" is a necessary precondition > for the run of isohybrid --uefi. > > > > Regarding current versions of the 3 tools built with cygwin, I only > > know of mkisofs. > > I know from user feedback that GNU xorriso gets built on cygwin > without problems. > > > > For instance, should the _isohybrid_ > > wiki page in Syslinux include details about ISO9660 or FAT or MBR or > > partition tables? > > I'd say no. > But it has to be mentioned that isohybrid is about adding an MBR. > It is necessary to know that for --uefi the ISO image has to contain > an EFI boot image, which is supposed to be a FAT filesystem. > It should also be mentioned that the boot path for UEFI is not > only El Torito and GPT but also a partition entry in MBR. > > That's just the immediate interfaces which isohybrid needs as input > or provides as output. > > > > http://cdrecord.org/ > > Ah yes. > > > > > If you see particular statements which are surplus under this > > > aspect, then we can discuss and eventually throw them out. > > > IMHO (not a strict list): > > Urm. That is a list of new topics, not of surplus statements in > my proposals. > > > > _ basic general concept, relevant for common user (one paragraph, > > something about "image bootable in optical media and USB drives"); > > I thought to have provided this in my proposal. > A motivation in the first two statements and then a quick tour with > several key terms and concepts. > > > > _ general "pros/cons" relevant for common users: the USB drive is > > overwritten, with one non-writable filesystem, part of the USB drive > > is not being used/seen; > > Yes. The whole discussion is still missing about suitable storage > media and how to put the image onto them. > > > > _ different variants exist, which ones are those variants; > > Three of them are presented in the BIOS paragraph. One of them > is not mentioned in UEFI because not capable of it. > > > > _ requirements and limitations: matching version with ISOLINUX in the > > ISO image, Perl OS-independent, based on C is OS (Linux) -dependent, > > possibility to produce images bootable in UEFI systems,...; > > This is mentioned for the both SYSLINUX tools. See bullet list. > xorriso dependencies and installation is not really in the scope of > the wiki. (I'd blatantly advertise GNU xorriso if i am invited to do.) > > > > _ respective command options for isohybrid variants, specially those > > included in Syslinux, > > That would be the job of a man page. > One could start with the quickly-made one from Ubuntu > http://manpages.ubuntu.com/manpages/natty/man1/isohybrid.1.html > > With -h or -s we get to the same undecidable discussions about > cylinder size which we had a while ago. We did not really make > progress with getting this well documented. > -e , -t, -i are MBR specific. > -o is a bit questionable, as a non-zero value will normally make > the partition unmountable. > --forcehd0, --ctrlhd0, --partok choose the built-in MBR template. > > They all need exploration and lots of background information. > > > > _ basic examples; > > I claim that > > isohybrid output.iso > > isohybrid --uefi output.iso > > are basic. > > > > _ resources, see also, more info... > > I take proposals. > > > > http://www.syslinux.org/wiki/index.php/Mbr > > Ahum. This this suggests that "hd0" in "--forcehd0" and "--ctrlhd0" > are about BIOS disk 0x80 and suffixes "_f" and "_c". > "--partok" would then select a flavour of "altmbr.bin" rather than > one of "mbr.bin". > > From section "Write" one could derive instructions about how > to put the image onto an USB stick by help of Linux. > > Probably the article should have a short introduction into > the concept of MBR. > I put a link to it into my proposal (if the captcha thing lets me). > > > > > > _ The firmware "target(s)" can be different than the one used by the > > > > host where the ISOLINUX and/or isohybrid image is being built. > > > Now you lost me. > > A user could be building an image so to be bootable in UEFI systems > > (too), but he is building such image in a BIOS system. > > Do we really have to explain that the firmware is not of importance > after the operating system has booted ? > > > > My point is, the options ("-u", "-m", "-b"...) are for the "target" > > system(s), and (at least some) combinations are allowed. > > This is indeed worth to be mentioned. > But it is not really specific to isohybrid, but rather to > the question what interfaces and early stage software has to > be offered to the intended boot firmware. > More or less the overall topic of SYSLINUX et.al. > > > > As one of Didier's questions suggests, the _alternative_ methods seem > > to be not clear enough. > > I am pondering about a translation table from isohybrid options > to isohdp[fp]x*.bin and the terminology in the Mbr article. > (Three terminologies for the same thing. Sometimes, choice is bad.) > > > > > I showed three of the variants: isohybrid.pl, isohybrid.c, xorriso. > > > The other two are not clear enough to me. > > > Do you mean from Slitaz? > > Yep. The .sh script and the .c program which both seem to perform > isohybrid for BIOS. But i did not analyze them in detail. > > > > -eltorito-platform 0xEF \ > > Now added to the UEFI section. (More example code, of course. Maybe > it should be presented without <pre>...</pre>.) > > > Have a nice day :) > > Thomas >@Thomas, Reading forum posts and the like, common users most frequently don't care about FAT, MBR, GPT, UEFI... The whole point of isohybrid is to try to simplify "burning" an ISO image to a (USB) drive. Users frequently want to know "step #1: do this, step #2 do that, step #3 reboot". Users with more experience / knowledge would probably avoid isohybrid for their own use, and install SYSLINUX/EXTLINUX instead. Regarding xorriso in cygwin... If someone has built xorriso under cygwin for his own use, good for them. Please forgive me for mentioning this yet again: common users. If there is a trustworthy site providing current versions of xorriso binaries built under cygwin, they are unknown to me. There is more than one site with cdrtools / mkisofs binaries built under cygwin, and at least one (which I consider trustworthy) maintaining updates for each new (alpha) release of cdrtools / mkisofs. That doesn't make it better than others; just available (for common users). I just posted comments as requested. They have no more value than others. Please go ahead and do what you think it's appropriate. Thank you, Ady. PS: If you want/need to, for a list of pages in the wiki, use "special pages" -> "all pages". There are more than 100 (certainly not all up-to-date).
> Hi, > > Ady: > > -eltorito-boot EFI/BOOT/BOOTX64.EFI > > This is most probably wrong, as this seems to be the prescribed > name for a file inside the EFI-understandable filesystem. > This filesystem would not be the ISO 9660 but rather the FAT > image file which serves as EFI boot image. > > > > -eltorito-boot EFI/BOOT/BOOTX64.IMG > > This might be better. From where did you learn that name ?This is just "the same" as the other one, "-eltorito-boot isolinux/efiboot.img" but with a path that is more appropriate for "all efi stuff is located in the same directory tree" ways.> > I still did not find information about how to create the FAT image. > My best guess for now is to simply install enough SYSLINUX in a > FAT filesystem image, so that it can chainload isolinux.bin from > the ISO filesystem. > https://wiki.archlinux.org/index.php/Syslinux#Installation_2 > > But that's just a speculation. Maybe somebody should peek into > Fedora Live CD: > > # mount -o loop Fedora-Live-Desktop-x86_64-20-1.iso /mnt/iso > # mount -o loop /mnt/iso/isolinux/efiboot.img /mnt/fat > $ find /mnt/fat/efi/boot > /mnt/fat/efi/boot > /mnt/fat/efi/boot/fonts > /mnt/fat/efi/boot/fonts/unicode.pf2 > /mnt/fat/efi/boot/grub.cfg > /mnt/fat/efi/boot/bootx64.efi > /mnt/fat/efi/boot/grubx64.efi > > Hrmpf. Obviously not SYSLINUX equipment in there. > > Anybody can shed light on that issue ?Unfortunately, at this time you won't find any ISO image that can boot by means of SYSLINUX.EFI from optical media; only with grub2-efi. You could find an ISO image that can be extracted and "installed" to a USB drive (not with ISO9660) and then this USB drive can boot using SYSLINUX.EFI, although they are either using an "old" version of Syslinux 6.xx, or are in some "beta" stage. The FAT image is used by grub2-efi, and has certain restrictions (e.g. alignment). Even some very popular posts / articles about this matter are incomplete. In theory, an ISO image with (some versions of) UDF could also be used to boot in UEFI mode.> > > Have a nice day :) > > Thomas >Regards, Ady.
> > > When > > > information is too-technical, or the wording sounds too-technical, > > > most users won't even read it. > > Although a "list lurker", I'd like to make a brief comment (stating the > obvious). > > Documentation will have different audiences, ranging from [sometimes > not-clueful] end-users to people trying to make distros bootable under > different conditions, to those who may want to learn enough background to > contribute to the project in some way. > > Each will complain differently when they use the Wiki, not only because the > information they're looking for is different, but because the background > each brings with them is different. > > I believe that reorganization of the documentation keeping this in mind > would be the "best" solution, rather than debating what to leave in or cut > out. There have been multiple times I've been interested in a piece of > software and wanted to find out its history so I could orient myself, and > some "helpful" soul had decided that all the old stuff was unnecessary and > deleted it. Conversations with long-time developers (when I could find > any) were required to learn things. It wastes time and is painful for > everyone. > > (No, I'm not volunteering -- I knew you were gonna ask. I don't know > enough to be able to make good decisions, someone would have to review and > clean up after me.) > > Please don't delete "old" or "useless" stuff. It *will* be useful to > *someone*. > > Also, If I'm trying to learn more about booting, it makes sense to dig into > this project. If you delete technical information that I need to know, > could I Google for it? Sure -- but it would be a lot easier if the > information were already here. It's a fine line between deciding what > information should be included in the docs here and what should be searched > for. But remember that searching isn't free in cost of the user's time. > If you delete information, at least insert a link to the information > elsewhere on the web (even knowing the link might go stale or missing). > > As far as marking software frozen, I would suggest that "frozen" is a value > judgement: if I want to work on it, then it's not frozen anymore, right? > If it's felt that it's deprecated or superseded for some reason, the > software should be annotated as such, together with the reason(s) why and > what would be required to make it up-to-date (if possible). If I'm then > attracted to use it or (God forbid!) work on it :-), then I would know what > I'm getting into and be able to intelligently decide if it's worth it and > how I might be hurt in the process. > > Sorry to interrupt your conversation. "Now back to our regularly scheduled > programming". Thanks for reading.Unfortunately, there is no way to write "for everyone". If the text is too-technical, common users won't read it, much less understand it. If it is "too-superficial", experienced readers won't read it and it would be almost useless for common users too. To be able to collaborate with writing helpful documentation, a potential writer would need to understand at least a little more than the common "incidental or "sporadic" user. To be able to collaborate with code, being capable of reading code is not optional. If someone wants to look a little back in history, looking at the git logs/diffs/commits is one possibility. So the wiki can't "contain everything", or use a "keep all info in, include all, don't delete any detail" style. This is not exclusive to the Syslinux wiki. Copying information that is available elsewhere is also not a good idea. When one site updates its content, users reading both texts can't decide which one is accurate. For these cases, linking to several alternative sources is more appropriate. Just as example... If someone has problems with some tool that uses Syslinux for building a USB bootable drive using FAT, he should ask that tool's developers, or maintainers, or in the respective distro's forum, before asking in #syslinux, or in this Syslinux Mailing List. It shouldn't be expected for the Syslinux wiki to solve all the issues for "something not booting". And yet, it is rare to see here (or in #syslinux) someone receiving no answer at all. Certainly more development-time/brains/fingers are needed, specially considering the expectations users frequently have about Syslinux. Regarding users that need to invest more time searching, "waa waa booo..." :D. Someone has to invest time to write code, someone has to invest time writing documentation, someone has to invest time testing... I wish the Syslinux Mailing List content would be indexed by respectable popular web search engines as it used to be (before 2012-Oct), but other than that... Users can type some words too; they will find the information. Let's move on to more practical matters. Regards, Ady.