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

[Ady]

> Hi,
> 
> intrigeri wrote:
> > FYI, Tails is still based on Debian 7 (Wheezy). Worse case, Tails
> > based on Debian 8 (Jessie) will be out early next year. Best case, I'd
> > say around November this year.
> 
> Until then, debian-8.0.0-amd64-DVD-1.iso and
> debian-8.0.0-i386-DVD-1.iso will test whether cylinder
> alignment matters for large images.
> 
> Their files /.disk/mkisofs tell the shell command which produced
> the ISO. debian-cd obviously left it to xorriso to find a cylinder
> size. In both cases it has chosen -h 237 -s 32 and aligned the
> ISO image size and the first MBR partition to that unusual size.
> The ISOs have exactly 1024 cylinders.
> 
> But the EFI System Partitions are represented in MBR as partition 2.
> Unaligned and nested, because they each mark a data file in the
> ISO image. So fdisk issues complaints.
> 
> These ISOs ignore about any cylinder tradition. If they work then a
> BIOS-only image aligned to -h 252 -s 63 is very likely to work too.
> 
> In general the Debian ISOs since version 6 have tested various
> intentional and unintentional deviations from cylinder alignment
> traditions.
> No user ever complained by bug report or mail to debian-cd list.
> It's just fdisk which is unhappy with cylinder fractions.
> 
> 
> Have a nice day :)
> 
> Thomas
> 
 
It is not just fdisk, and it is not just cylinder alignment. 
Potentially, it is _any_ partitioning tool with _any_ kind of default 
alignment.

For instance, different versions of fdisk use different default 
alignment. Newer versions even support GPT too.

Additionally, the specific available "units" are important. Some 
versions of some partitioning tools default to use "cylinders" as unit, 
whereas others default to "MiB". Some partitioning tools offer the 
possibility of "bytes" as unit, and others have "sectors" as 
alternative. Many GUI partitioning tools only allow "MiB", specially 
those with GUI.

And then we have all sorts of algorithms for default CHS values in 
different BIOS versions and in each partitioning tool. Just as a 
generic example, you will find that for certain (virtual) device sizes, 
qemu's BIOS defaults to a certain CHS geometry, whereas the same exact 
raw image is seen by VirtualBox's BIOS with a different CHS geometry.

This is why I said (in 2015Feb) that, if I couldn't choose the H/S pair 
255/63 for an image between 1 and 2 GiB, I would choose 128/63. Note 
that some USB drives don't even report 63 sectors_per_track in reality, 
but rather other SPT values, multiple of 4.

When using dd-like methods to "burn" an isohybrid image to a (USB 
flash) storage drive (as opposed to using optical media) with the goal 
of using it as read-only media (and nothing more), the CHS values would 
rarely matter in nowadays hardware in terms of the ability to boot and 
to correctly read its content. Please note that I am not making 
references to performance, only to the potential chances of booting the 
broadest range of systems.

The problem with using less-than-very-common CHS geometries starts with 
the other cases, when using multiple partitions (e.g. after the initial 
dd task) or when not using dd-like methods.

If the CHS geometry would not matter at all, then we would not be 
recommending any particular pair of values, ever.

Let's remember what's the main goal of using isohybrid: to simplify 
*for unaware users* the initial "burning" of the image onto different 
media (types). This is why I am proposing that the resulting isohybrid 
image size should default to a multiple of 2048. If the "user" (the 
person building the isohybrid image) wants to minimize the additional 
padding, then an optional parameter should be available.

The "truncate" workaround is just a quick dirty trick, effective for 
certain cases (like for current TAILS, apparently). When using 
isohybrid images with GPT (too), the truncate workaround might possibly 
be not a good choice. Using values of H/S in the isohybrid command line 
is already more than some distro maintainers are doing -- a pity, if I 
may say so.

Perhaps there are additional things that the isohybrid tool could do to 
reduce the issues with some partitioning tools, but that's another 
discussion for a later time.

For this discussion, IMHO:
_ using the adequate "align_factor" should be the default behavior for 
the isohybrid tool(s);
_ reducing the zero-padding (by means of not using the ideal 
"align_factor") should only be an optional, not the default;
_ we should be very careful / specific if we ever claim that the CHS 
geometry has no effect on the ability to boot, as this is not a valid 
claim in generic terms but only under certain limited circumstances;
_ lack of error-reporting might not be enough proof that "everything is 
OK", as the potential reporter would need to know the exact reasons, be 
willing to report it, be willing to invest the time to actually report 
it in such a way that would be replicable and understandable by others, 
and the respective maintainers would need to be willing to do something 
useful about it.

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