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

Hi,

Ady wrote:
> I fear we would get slightly off-topic.
Yep. Since the TAILS ISO is supposed to not grow over 2 GiB
for now, it seems best to just use -h 128 -s 32 in order to
stay near to traditions.


-----------------------------------------------------------
Summary:

The alignment to cylinder size is a core feature of isohybrid.
If -h multiplied by -s is not divisible by 4, then ISO image
files may emerge from isohybrid which are not aligned to
2048 bytes. This is bad if the file shall be used as
virtual DVD-ROM.

The waste caused by a particular cylinder size depends on
the size of the ISO input image.
It is well possible to automatically determine a cylinder size
for minimum waste while keeping it divisible by 2048.
But it would probably produce non-traditional sizes.
(Whatever the importance of a traditional size is.)

It might be beneficial for the community if everybody tests
-h 252 -s 63 whether it suits as replacement of the advise
to use -h 255 -s 63 with large ISOs.

-----------------------------------------------------------

Have a nice day :)

Thomas

> Hi,
> 
> Ady wrote:
> > I fear we would get slightly off-topic.
> 
> Yep. Since the TAILS ISO is supposed to not grow over 2 GiB
> for now, it seems best to just use -h 128 -s 32 in order to
> stay near to traditions.
> 
> 
> -----------------------------------------------------------
> Summary:
> 
> The alignment to cylinder size is a core feature of isohybrid.
> If -h multiplied by -s is not divisible by 4, then ISO image
> files may emerge from isohybrid which are not aligned to
> 2048 bytes. This is bad if the file shall be used as
> virtual DVD-ROM.
> 
> The waste caused by a particular cylinder size depends on
> the size of the ISO input image.
> It is well possible to automatically determine a cylinder size
> for minimum waste while keeping it divisible by 2048.
> But it would probably produce non-traditional sizes.
> (Whatever the importance of a traditional size is.)
> 
> It might be beneficial for the community if everybody tests
> -h 252 -s 63 whether it suits as replacement of the advise
> to use -h 255 -s 63 with large ISOs.
> 
> -----------------------------------------------------------
> 
> Have a nice day :)
> 
> Thomas
> 
 
I am not so sure that using a different pair of '-h' and '-s'
values
would be better than using 255/63. Most BIOS and most partition editors 
would assume this geometry. Using a different geometry might help when 
using the resulting isohybrid image as virtual optical media, but might 
also reduce the chances of successfully booting in some BIOS systems 
with non-optical media.

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 wonder whether my suggestion for the algorithm is inadequate, or 
whether it would modify in some way any other condition already 
included in the isohybrid source code. If it does, then perhaps it 
would be possible to combine them?

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?

I would tend to think that the resulting isohybrid image size should be 
a multiple of 2048 bytes (independently of the command-line parameters 
chosen by the user), and that the isohybrid tools should try to match 
this condition. What currently-existing condition would not be achieved 
in such case?

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

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