Syslinux - Feb 2015 - isohybrid and ISO images whose size is not a multiple of 2048 bytes vs. VirtualBox

Hi,

intrigeri wrote:
> We're using `isohybrid -h 255 -s 63' [...]
> isohybrid produces ISO
> images whose size is not a multiple of 2048 bytes.
Seems to be intentional.

http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/utils/isohybrid.in
  # Target image size: round up to a multiple of $h*$s*512

http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/utils/isohybrid.c
    cylsize = head * sector * 512;
    frac = isostat.st_size % cylsize;
    padding = (frac > 0) ? cylsize - frac : 0;

With -h 255 -s 63, both pad to an integer number of cylinders
with an impair multiple of 512 bytes. So if the number of
cylinders is not divisible by 4, then the number of bytes is
not divisible by 2048.

An ISO image may have a fuzzy end, but a virtual CD-ROM
should indeed provide an integer number of 2048-byte blocks.

> truncate -s %2048 $ISO
This makes the image larger than the partition.
Not overly unhealthy, i'd say, because the ISO filesystem
still fits into the partition.
Nevertheless not totally clean.
Does fdisk -lu complain ?


An alternative would be to request a cylinder size which
is divisible by 2048. E.g.

  isohybrid -h 252 -s 63

The cylinder sizes 64x32 and 255x63 emerged as best
candidates when we compared our collections of questionable
experience and rumors. More substance is not to see behind
them.
(Actually Cylinder/Head/Sector addressing is so brain
 damaged that only ill firmware can insist in it having
 a particular form. All sane firmwares will simply use
 LBA numbers for addressing.)


Ady wrote:
> For isohybrid images, the result should be a multiple of 1MiB (1048576 
> bytes), which is itself a multiple of 2048 bytes.
This is possible only up to an image size of 1024 MiB,
because the cylinder field allows numbers from 0 to 1023.
For larger images the current isohybrid advise is
indeed -h 255 -s 63 (ends shortly before 8 GiB).

The found problem should make us rethink and trigger
massive testing.

> I don't know whether there is some bug in any one of the isohybrid 
> tools included in Syslinux (there might be).
No. This time it is a conceptional problem of isohybrid.
It wants to be an MBR partitioned hard disk and a CD-ROM
at the same time. I am quite sure that VirtualBox does
not complain about the ISO filesystem but about the
virtual DVD-ROM.

If isohybrid pads to a cylinder size, then it would be
odd to add further 1, 2, or 3 blocks of 512 bytes.
I think the workaround with truncate is a valid way to
override the valid decision of the isohybrid program
... if one cannot affort a cylinder size that is
divisible by 2048.


Have a nice day :)

Thomas

> An alternative would be to request a cylinder size which
> is divisible by 2048. E.g.
> 
>   isohybrid -h 252 -s 63
> 
> The cylinder sizes 64x32 and 255x63 emerged as best
> candidates when we compared our collections of questionable
> experience and rumors. More substance is not to see behind
> them.
> (Actually Cylinder/Head/Sector addressing is so brain
>  damaged that only ill firmware can insist in it having
>  a particular form. All sane firmwares will simply use
>  LBA numbers for addressing.)
> 
 
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 while maintaining a "sane" file system. This 
is the reason for the recommended '-h' and '-s' values.

I'd rather not comment (at least, not at this opportunity) on the 
(minimal and preferred) conditions to be (hard-code) included in the 
source code.

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}) instead of completely 
arbitrary values. That is, in addition to making the total size a 
multiple of 2048 bytes, avoiding partial cylinders and maintaining the 
resulting amount of cylinders to equal or less than 1024.

Regards,
Ady.

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