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

[Thomas Schmitt]

Hi,

Ady wrote:
> Let's not forget that the goal usually is to select CHS values so that 
> the resulting (optical and/or other) media would boot correctly in as 
> many systems as possible 

Agreed. But we now have a report about failure of 255x63
on a popular pseudo-hardware, when the ISO is presented
as DVD-ROM. (Probably there is no complaint when it gets
presented as hard disk.)

We do have statements by hpa that cylinder geometry can
matter. But actually i am not aware of a particular
example, from which we could judge whether 255x63 is
essential for any popular hardware/firmware.


> Now, if the proposed (temporal?) workaround is to use a different pair 
> of '-h' and '-s' values, I would suggest choosing them according to 
> commonly-used conventions or standards for CHS translations (e.g. 
> h={15,16,32,64,128,240,255}; s={16,32,63})

Are there any standards ? We mainly have traditions
in this aspect.

C/H/S addressing is relying on an unstable concept which
actually assumes that the software can detect the cylinder
size from the storage device. Since decades those drum
storages and early hard disks are gone. There is no cylinder
any more. The number of physical read heads has decreased
to at most a handful, if not a single one. 

Partition editors make daring assumptions from the
comparison of LBA and CHS of the end addresses of
partitions. If these assumptions turn out to be inconsistent,
then e.g. fdisk issues complaints like:

  Partition 1 has different physical/logical beginnings (non-Linux?):
  Partition 1 has different physical/logical endings:

This is the main reason, which i personaly know, why it is
helpful to assume a particular CHS geometry and to aling
the ISO image to a full cylinder size.

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