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

[Ady]

> I proposed -h 252 -s 63 because it yields the largest
> possible cylinder size which is divisible by 4 (i.e.
> the byte count is divisible by 512*4 = 2048).
> -h 240 -s 63 would fulfill this constraint, too.
> Size limits are 252*63*1024*512 = 8,323,596,288
> resp.           240*63*1024*512 = 7,927,234,560 bytes.
> 
> 
> The workaround cannot be temporal, because the problem
> is fundamental.
> We have two candidates for a remedy:
> - Pad up to multiple of 2048 bytes (e.g. by truncate)
> - Use a cylinder size in bytes which is divisible by 2048.
> 
> The pad-up method is equivalent to what a burn program
> would have to do when putting the ISO onto a CD or DVD.
> 
> 
> Have a nice day :)
> 
> Thomas
> 
 
The largest "'head' multiple of 4" would be as valid as using a 
different pair of values that would cover the total size of the ISO 
image. And, with "temporal" I meant that users can supply whatever they 
want (to the isohybrid tools included in Syslinux) as 'heads' and 
'sectors_per_track' values without changing the source code (or without 
waiting for a new release).

So, while choosing 255/63 has some intentional purpose, choosing 252/63 
is as arbitrary as choosing, for instance, 240/63, or 128/32, with the 
difference that "252" does not coincide with any particular size 
limitation while "240" and "128" partially do (note that all these 
pairs would still cover the relevant size we are talking about in this 
example of TAILS, slightly over 1GiB). There are other potential 
advantages for smaller values, but successfully booting as many systems 
as possible should be the primary target.

And yet, all this doesn't really matter, as different BIOS could assume 
different values, whether because they use different algorithms to 
select CHS values / translation methods, or because some bug (in the 
BIOS; I would be shocked :o :D). This is the reason for the recommended 
values (255, 63) for a size from 1GiB and up.

The 'h' and 's' values are related to BIOS issues (CHS translations and 
size limitations). OTOH, the algorithm in the isohybrid tools being 
used to calculate the size of the resulting ISO image and the values 
for the boot code / partition table (to be inserted into the original 
ISO image by the isohybrid tool) are indeed related to partition 
editors (cylinder boundary), and to potential performance (and 
potential wear out) of storage media (e.g. so called "flash / pen 
drives" and SSDs).

So let's attempt to list the minimal conditions, and the additional 
desired (preferred) conditions, for the algorithm:

1_ The resulting ISO9660 file system size shall be a multiple of 2048 
(bytes_per_sector).
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).
4_ The additional zero-padding tail (so to match the calculated 
complete cylinder and partition size) should be as minimal as possible.
5_ Let's not forget that the primary goal is still maximum 
compatibility with as many firmwares as possible (so users should 
choose the values of 'h' and 's' accordingly and wisely).
6_ The resulting size of the isohybrid image should better be a 
multiple of 1MiB.
7_ The starting absolute offset of the resulting partition should 
better be a multiple of 4KiB.

If the amount of cylinders would be a multiple of 2048, we would 
achieve #1 and #2 (and then #3), but not always #4. One possibility to 
help with #4 would be to loop the expected calculations of cylinders 
and resulting image size (please avoid reading the following as real 
code or calculations; it is not):

 "cylsize = head * sector * 512*1" ... ;
 evaluate the expected resulting size (multiple of 2048 bytes, and 
complete cylinders for the partition) ;
 "cylsize = head * sector * 512*2" ... ;
 evaluate the expected resulting size (multiple of 2048 bytes, and 
complete cylinders for the partition) ;
"cylsize = head * sector * 512*3" ... ;
 evaluate the expected resulting size (multiple of 2048 bytes, and 
complete cylinders for the partition) ;
"cylsize = head * sector * 512*4" ... ;

The above is not a precise and adequate pseudo-code (not even close), 
but my intention is just to present the general idea. My point is, if 
the first loop achieves the minimal (necessary) conditions, then the 
ISO image can be modified using such calculated values; but if not, 
then re-calculate with the next loop... until the calculations fulfill 
the expected minimal conditions and use the last calculated values to 
actually modify the original ISO image.

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

Regards,
Ady. 

> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>