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

[Ady]

> Hi,
> 
> Ady wrote:
> > my suggestion to modify the _amount_ of Cylinders was intended to 
> > overcome the "by 4" (or rather, "by 2048") issue.
> 
> Now i get your intention. You want to align the
> resulting ISO to 4 full cylinders in order to avoid
> the need for a cylinder size divisible by 4.
> 
 
No :). I want to align to resulting isohybrid image size to 4 full 
cylinders *only when necessary*.

Depending on the values of Heads and Sectors_per_track (whether they 
are command-line parameters the user established, or whether they are 
the result of other command-line parameters the user might have used), 
the amount of Cylinders might not need to be a multiple of 4 (e.g. '-h 
64 -s 32').

But it also depends on the size of the ISO image (see calculations 
below).

If the first loop (in my suggestion) being used to calculate an 
attempted Cylinders (amount) is good enough, then the rest of the 
algorithm would continue. If it is not, add +1 to the first attempted 
Cylinders (amount) value and calculate the potential result. Check 
again; is it good enough? If it is, use that value of Cylinders 
(amount) and continue. If it is not, add +1 again and loop.

If the input ISO image is adequate (i.e. its size is a multiple of 2048 
bytes), then a maximum of 4 loops would be necessary. When a useful 
value of amount of Cylinders would be calculated, only _then_ move on 
with the rest of the conditions and actions. I mean that there are 
_not_ 4 attempts to actually build the isohybrid image, but only a 
maximum of 4 loops of calculations for the potential amount of 
Cylinders and the potential resulting isohybrid image size.

Now, say we have a "good" set of potential CHS values such as 
2048*255*63 so to calculate the resulting size of the isohybrid image. 
That's good for the _size_, but such amount of Cylinders is too big for 
the partition table. This condition should already be part of the 
source code (apologies, I am not a developer, so I don't have the 
knowledge to check whether this last assumption is true). Then you use 
the already-existing conditions so to use the maximum value allowed for 
the partition table (1023), as you would usually do. Just as with the 
current algorithm, the resulting size is bigger than what the partition 
table allows; nothing has changed.

The purpose of the suggested loop (instead of immediately using an 
amount of Cylinders multiple of 4) is to minimize the zero-padding.

For example, if we were to need '4*255*63*512-1' additional bytes, that 
would be less than 32MiB to be added to the input ISO image. If the 
input image size was around 1.2GiB, that's less than %2.56. Depending 
on the exact size of the ISO image, it could also be much less (the 
suggested loop would decide). For a geometry of 64/32 (for a size lower 
than 1GiB), the suggested zero-padding would result in the very minimal 
size, for any/every size of the ISO image.

Let's repeat the background calculation (please do not interpret the 
following pseudo-code as actual functions / operations in C, it is 
not):

Cylinders=
  trunc(roundup( ISO_size / (Heads * Sectors_per_track * 512))

where 'ISO_size' is the size, in bytes, of the input ISO image.

 (Note: roundup(n.0) = n)

So, depending on the potential set of values (ISO_size, Heads, 
Sectors_per_track) the minimum amount of Cylinders might need to be 
some "i" value, or "i+1", or "i+2" or "i+3" (assuming ISO_size is an 
adequate value, multiple of 2048 bytes). This is the loop.

Let's repeat it, for clarity:
1_ Calculate a potential Cylinders (amount) value;
2_ Calculate 'Cylinders * Heads * Sectors_per_track';
3._ Is the result of the calculation (as explained in the previous step 
#2) a multiple of '4'?
3.a_ If it is, continue (to step #4);
3.b_ If it is not, then add '+1' to the attempted Cylinders (amount) 
value and loop to step #2.
4_ Other conditions and logic already present in the isohybrid source 
code still apply (e.g. the Cylinders value could be too-high for the 
partition table, in which case the value for the partition table is 
truncated to the maximum allowed value; the input ISO image size shall 
be a multiple of 2048 bytes...).

The actual code necessary to achieve to 4 loops could be actually not a 
loop, of course. That's beyond my knowledge (had I knew how to code it, 
I would had sent a patch). Whichever the code (style, method,...), 
there are up to 4 calculations attempts.

Hopefully I am explaining it better this time.

Regards,
Ady.