[syslinux] isohybrid question

[Thomas Schmitt]

Hi,

me:
> > http://syslinux.zytor.com/archives/files/2010-March/013905.html
hpa:
> I really don't like it,

I understand that you would prefer to make
hardcoded constants out of my proposed header
info.

The remaining long-term variable info shall be
read from bytes of the MBR which get overwritten
anyway when the MBR is placed in the ISO image.

In principle that seems viable.
I just deem explicit headers more straightforward
and easier to describe in docs.
I also think it is better prepared for future
changes. Especially since storage space inside
the MBR is sparse.


------------------------------------------------
Detail discussion:

> in large part because it embeds in the file
> things that would be better passed directly to xorriso, 

xorriso (actually libisofs) has no clue about
hard disk geometry or BIOS limitations.
So these three proposed header lines would
transfer the necessary knowledge from syslinux
to libisofs:
  Num-h: 64
  Num-s: 32
  Limit-cc: 1024
libisofs needs them because they are part of
computations with boot image the LBA resp. the
ISO image size.

This here would allow syslinux to change the
position of the bootimage address word within
the MBR:
  Bin-block-field: 432


> Otherwise I need to add a CLI tool to manipulate these files just so the
> user can set these options, which really doesn't make any sense whatsoever.

For now you could just hardcode them.

The proposed header format would allow you to 
change them in future syslinux versions. Then
it would come in handy if the readers already
take them from the file.

Also: New incompatible MBR formats could be
indicated by a new header.
The reader would then know that this MBR is not
suitable. Still better than producing an ill
ISO image that won't boot.


The CLI tool would be necessary anyway to apply
the syslinux specific user options to the
template MBR before libisofs puts it into its
image stream.

My proposal would not make isohybrid obsolete.
It would rather give it a second job:
To produce MBR templates by the same parameters
which can be used to patch existing ISO images.

Usage model:
a) Prepare MBR template
  Loop:
  b) Prepare ISOLINUX files on hard disk
  c) Let libisofs create an ISO image from the
     hard disk files and the MBR template.

Typically a user will have to create a new MBR
template only when upgrading the syslinux
installation.
(One could also provide a ready-to-use template
 among the syslinux release files.)


> to allow a System
> Area file to be created without the isohybrid extensions, but I think
> that's already supported in the form of the -G option to mkisofs (I
> assume xorriso is compatible with the mkisofs interface, although I
> haven't looked myself.)

There is a mkisofs emulation in xorriso.
-G is not implemented yet, because i have no use
case for it.

-G does not meet our requirements because a
isohybrid MBR needs to get inserted some data
which only libisofs knows before the ISO image
is written.

I have to insert the boot image LBA at byte 432
  lsb_to_buf(&wpt, bin_lba * 4, 32, 0);
and image size in bytes 458-461
  cylsize = h * s * 512;
  ...
  c = imgsize / cylsize;
  ...
  lsb_to_buf(&wpt, c * h * s, 32, 0);

There are also bytes 453 (cc is either c or 1024)
  /* esect */
  lsb_to_buf(&wpt, s + (((cc - 1) & 0x300) >> 2), 8, 0);
and 454
  /* ecyl */
  lsb_to_buf(&wpt, (cc - 1) & 0xff, 8, 0);


> As such, the format of bytes 432..511 is fixed anyway. Perhaps what we
> can do is use those bytes in the System Area image to point to the
> signature in the boot file:
> - Offset 432 contains the offset within the boot image for the
>   signature;
> - Offset 436 contains the length of the signature;
> - The remaining bytes is the content of the signature string.

Bytes 440-443 contain the id word which i would
prefer to read from the MBR rather than producing
a random id in libisofs.


Have a nice day :)

Thomas