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

[Thomas Schmitt]

Hi,

Ady wrote:
> I am not so sure that using a different pair of '-h' and '-s' values 
> would be better than using 255/63.

But 255 * 63 is not divisible by 4 and thus can cause
trouble with virtual DVD-ROM.

> Most BIOS and most partition editors would assume this geometry.

I cannot tell for BIOSes, but partition editors have options
to set heads-per-cyl and sectors-per-head. At least fdisk
makes guesses from comparing LBA and CHS of the partition ends
under the assumption that each partition ends at a cylinder end.


> Additionally, what do you mean with "non-traditional sizes"? Or, in 
> other words, what would constitute a traditional size for the resulting 
> isohybrid image?

I mean non-traditional cylinder sizes.
Advised by hpa are 64x32 and 255x63, but i assume that he
was not aware of the problem of virtual DVD-ROMs not being
aligned to 2048-byte blocks.

So in the light of this thread it would be nice if the advise
for 255x63 could be changed to 252x63. Question is whether this
could cause any regressions with boot firmware. (Partition
editors should be happy with partition ends aligned to cylinder
ends.)


> I wonder whether my suggestion for the algorithm is inadequate

If i understand it right, then it shall look for a cylinder
size with minimal waste. That would be adequate but could produce
non-traditional cylinder sizes without the user being aware of
this. So i'd rather not advise this.

If i misunderstand your intention and you want to manipulate
the overall ISO image size, then this is inadequate because
it collides with the isohybrid feature to align the ISO image
end to the next cylinder end.
(Note well that only the image file is enlarged by isohybrid.  
 The filesystem size of the ISO stays as it was with the input
 ISO image file.)

The algorithm suffers from the wrong assumption that cylinder
size could be incremented in single block steps. It rather has
to be composed of the two factors -h {1...255} and -s {1...63}.
Some sizes are simply not possible that way. E.g. 4 MiB.
Cylinder size enumeration can be well done by two nested loops.
One for -h and one for -s.


> If different "preferred" conditions go against each other, perhaps 
> there should be some argument for the user to choose which conditions 
> are more relevant / important for his goal / needs?

But how to explain all this mess ? Even we two have problems
to get a common understanding.

The first problem is that none of the contraints discussed
here is covered by an official standard. ECMA-119 (aka ISO 9660)
simply bails out by stating that the first 32 KiB of an ISO
are designated for arbitrary system dependent data.

isohybrid chooses to put an MBR there, possibly a GPT,
and possibly an APM. All three are not designed to coexist
with the other two in the form they have:

MBR collides with APM. This is circumvented by special x86
machine commands at the start of the MBR, which cause no
side effect if executed by an x86 processor, but also look
like a Apple Partition Map Block 0 which announces block
size 2048 and a phony size of the overall image file.
It works for booting some Macs, but already Linux would
refuse to mount the HFS filesystem in the APM partition,
because Linux has block size 512 hardcoded for HFS.

GPT demands that the MBR must be a "Protective MBR".
I.e. it must show a single partition of type 0xee,
which reaches from LBA 1 to the end of the block range
that is covered by GPT.
isohybrid makes a MBR with first partition of type 0x17
and partition start at LBA 0, so that the partition is
mountable as ISO filesystem.
Further GPT/UEFI specs demand a backup GPT at the end of
the storage device. When isohybrid makes the ISO, it
cannot predict what size the final storage device will
have. So on the storage device, the backup GPT will
end up at the wrong position.

APM is not aware of MBR or GPT. Its Block 0 occupies
the same byte range as the MBR.
The isohybrid MBR exposes a minimal mock-up of an APM
Block 0 which seems to suffice for some Mac firmwares.
APM plus GPT needs an APM block size of at least 1024 to
leave room for the GPT header block at LBA 1.


It seems unfair and without much hope for success, to
put the decision on the user, who already is occupied with
the peculiarities of her/his booting operating system
and the storage devices from where it may come.

We need a simple, straight advise for the user.
Like:
"Use -h 64 -s 32 for small ISOs and -h 252 -s 63
 for ISOs over 1 GiB."


> I would tend to think that the resulting isohybrid image size should be 
> a multiple of 2048 bytes [...]
>  What currently-existing condition would not be achieved in such case?

The holy rule of cylinder alignment.

Of course this would be no show stopper:
Debian distributed several ISOs which were not aligned
to cylinder size because of a xorriso bug. No complaints or
bug reports emerged from this. Only fdisk was unhappy.

I assume the TAILS ISO with -h 255 -s 63 behaves the same
after it was padded up by program truncate.


Have a nice day :)

Thomas