[syslinux] isohybrid question

[Thomas Schmitt]

Hi,

H. Peter Anvin wrote:
> My preference would be if we can do the integrated generation without
> having to hard-code the actual MBR sequence; i.e. to produce a data file
> out of the Syslinux build that can be fed into your tool.

Yes. My proposal of last year was to have an
array of 
  struct isohybrid_mbr {
      int version;
      char mbr_code[512];
      int num_ibsigs;
      char desired_ibsigs[10][4];
  };

Component .version gives the version of this
struct layout. We'd start with 0 and increment
if new components are introduced.

The MBRs could be expressed as single .h files
with a master .h that puts the various structs
into an array.
For producing such MBR .h files one would have to
bring together the MBR code and the info about
the magic numbers in isolinux.bin for which the
MBR is valid.


Alternatively we could define a file format
for reading the MBRs at run time of the isohybrid
generator.

Whatever format: The production of such MBR
packages would be a job for Syslinux.
They should have a permissive license so that
they can be used by all interested programs.


> The handling of forcehd0/ctrlhd0/partok can be dealt with by
> selecting different MBR files

So we have to expect multiple valid MBRs for
the same isolinux.bin ?

In that case above struct should get a .name
component by which the MBR can be selected.
Like:

  struct isohybrid_mbr {
      int version;
      char name[80];
      char mbr_code[512];
      int num_ibsigs;
      char desired_ibsigs[10][4];
  };


------------------------------------------------
About the related issue of ISO images which can
be mounted on Linux as /dev/sdb and /dev/sdb1
alternatively:

> > Another point is that the offset must be at least
> > 38 kB, better 64 kB.
> I'm not entirely sure how you get this... arguably it would be better if
> it was exactly 32K, which would put the "real" PVD inside the partition.
> It means the alternate PVD would end up at sector 32.

You are right. We could put the first volume
descriptor set into the System Area of the
second set.

So the question with this is now:
Would it be worth the effort ?
(Are there users ready for testing ?)


I meanwhile think we would need no second
El-Torito record. The one at block 17 should
be the only one visible to the BIOS when the
image is on CD.

The default layout would then be:

  sdb LBA  sdb1 LBA    Content
  ---------------------------------------------
   0       (-16)       MBR (+ boot helper code)
  16          0        PVD 1
  17          1        El-Torito
  ...       ...        (other descriptors) 
  x<32      x<16       Volume Descriptor Set
                       Terminator 1
  32         16        PVD 2
  ...       ...        other descriptors and
                       Volume Descriptor Set
                       Terminator 2

After this come two directory trees which
differ only by an offset of 16 in all LBA
fields.
Each alternative PVDs would point to the root
of its matching tree.

>From the view of ISO 9660/ECMA-119 this should
work with any interpreter of the image.


But what influence does the address ambiguity
have on isolinux.bin ?
For now i have to tell it its LBA when the
ISO image gets prepared.

>> patching the entry of the LBA of isolinux.bin
>> into offset 432

So with this we would need two isolinux.bin ?

> Arguably we could even do a full-blown El Torito simulator in the 32K
> available, and even skip this requirement...

This looks like a solution. No patching, no LBAs
stored outside the official meta data of the
image.

Do we have any other entity in an ISOLINUX image
which would know an LBA by itself and not by
interpreting the meta data of the image ?


Have a nice day :)

Thomas