> 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.