[syslinux] isohybrid and ISO images whose size is not a multiple of 2048 bytes vs. VirtualBox

Thomas Schmitt scdbackup at gmx.net
Wed Feb 18 11:22:40 PST 2015


it would be interesting to know for what solution
TAILS decides and whether any problems arise with it.

On with the fundamental discussion of MBR cylinders:

Ady wrote:
> 1_ The resulting ISO9660 file system size shall be a multiple of 2048 
> (bytes_per_sector).

The known ISO production programs comply to this condition.
(Theoretically there could be other block sizes between
 512 byte and 64 KiB. But 2048 is the address granularity
 of optical media and so no other block sizes have been seen

> 2_ The resulting size of the isohybrid image shall be a multiple of 
> 2048 bytes.
> 3_ The resulting partition size should better match the end of a 
> complete cylinder (the latter is the value to be calculated and 
> optimized).

Would #3 allow that the ISO image file size is larger than
the partition size ? Like the result of the truncate
workaround ?

> If the amount of cylinders would be a multiple of 2048,

You mean the size of a single cylinder, i assume.

> we would achieve #1 and #2 (and then #3),

If the ISO image file shall end exactly at the partition
end, then #2 and #3 go together if and only if the cylinder
size is a multiple of 2048, which is equivalent to the
product of -h and -s being divisible by 4.

> but not always #4.
> [...hopping back ...]
> 4_ The additional zero-padding tail (so to match the calculated 
> complete cylinder and partition size) should be as minimal as possible.

It is determined by the remaining space up to the next
cylinder end. 

There are only 2 exp 14 possible cylinder sizes of wich
only 2 exp 12 = 4096 are divisible by 2048. So this invites
brute force. :)) 
I.e. try all cylinder sizes which are larger than or equal
to (ISObytesize / 1024) and memorize the one with the least
waste. (The loop(s) can end prematurely if waste 0 is

> 6_ The resulting size of the isohybrid image should better be a 
> multiple of 1MiB.

I am not sure whether this can be deduced from the
traditions. We only know that a cylinder size of exactly
1 MiB gives much hope for success.
But i understand that TAILS ISO production uses
-h 255 -s 63 because the ISO grew above 1024 MiB.
So cylinder size 1 MiB is not suitable.

> 7_ The starting absolute offset of the resulting partition should 
> better be a multiple of 4KiB.

This one is new to me.
What can possibly happen if it is not fulfilled ?

Well, isohybrid MBR partition 1 has to begin at LBA 0
in order to make it mountable, unless the ISO was
produced by xorriso with -partition_offset to create
a suitable second superblock and file tree.
The advisable -partition_offset is 16 * 2 KiB.

So the 4 KiB condition is more or less always fulfilled
for the first partition of an ISO, after isohybrid is
done with it.
But it is not fulfilled with partitions which emerge
because options --gpt and/or --apm are used.

> BTW, let's not forget that applying the isohybrid tool to an 
> already-isohybrid image will make a mess of the resulting image. 

Does it ? It should not.
What are the symptoms of mess ?

> Isohybrid tools should better inform the user and ask whether to 
> continue anyway when the input image is not a "normal" (not isohybrid) 
> ISO image.

The only condition an ISO has to fulfill for isohybrid
is that it bears as first El Torito boot image the
isolinux.bin BIOS boot image from a SYSLINUX release which
is modern enough to also offer the isohybrid tool.

The tools check this and eventually complain:

  if ($ibsig ne "\xfb\xc0\x78\x70") {
      die "$0: $file: bootloader does not have a isolinux.bin hybrid signature.".
          "Note that isolinux-debug.bin does not support hybrid booting.\n";

    if (memcmp(buf, "\xFB\xC0\x78\x70", 4))
        errx(1, "%s: boot loader does not have an isolinux.bin hybrid " \
                 "signature. Note that isolinux-debug.bin does not support " \
                 "hybrid booting", argv[0]);

isohybrid.c with combined options --gpt and --apm fails
on xorriso produced ISOs, because of inappropriate
assumptions about the structure of an El Torito boot
catalog. See this thread:

Have a nice day :)


More information about the Syslinux mailing list