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

[anonym]

[I was dropped from cc in the initial response but I'd appreciate if you
could keep it this time around since I'm not subscribed to this list.
Thanks!]

Ady wrote:
> I do not know the exact complete procedure that the TAILS team is using 
> to build the original ISO image, and how it is transformed into an 
> isohybrid image (there are multiple tools for each, sometimes 
> combined).

We end up generating the (non-hybrid) ISO image with something like this:

    genisoimage -J -l -cache-inodes -allow-multidot -A "The Amnesic
Incognito Live System" -p "live-build 2.0.12-2;
http://packages.qa.debian.org/live-build" -publisher
"https://tails.boum.org/" -V "TAILS 1.2.2 - 20141212" -no-emul-boot
-boot-load-size 4 -boot-info-table -r -b isolinux/isolinux.bin -c
isolinux/boot.cat -o binary.iso binary

Then we post-process it into a hybrid ISO image by running `isohybrid -h
255 -s 63 $IMAGE`.

> If the isohybrid method (whichever tool you are using) is not applied 
> to your original ISO image, is such ISO image' size a multiple of 2048 
> bytes?

I would say yes. We haven't had this issue before re-introducing
isohybrid in the mix. I say "re-introduced" because we used isohybrid
years ago but then it was not problematic either. Back then we ran it
with the `-entry 4 -type 1c` options only, so no -h or -s. Also, back
then all images (no matter which compression we used) were definitely
far below 1GiB in size, which may be relevant information for your later
question.

> What's the difference, in bytes, between the non-hybrid ISO image and 
> the isohybrid one? Could you please provide both exact sizes?

Our current stable release [1], which wasn't a hybrid ISO, is 951764992
bytes. If I run `isohybrid -h 255 -s 63` it becomes 954132480 bytes
which is a multiple of 1MiB (and hence 2048 bytes too). This seems to
happen for all of our stable releases I tried, and they're all below
1GiB in size...

[1]
http://dl.amnesia.boum.org/tails/stable/tails-i386-1.2.3/tails-i386-1.2.3.iso

> It is 
> possible that some "limit" (e.g. around the 1GiB) might be triggering 
> some condition (I am not saying that this is a bug in the isohybrid 
> tools, or that such case might trigger a problem; just assuming that 
> there might be some potential chance that some case might have not been 
> considered in the source code).

... so this would explain a lot. I've actually only seen the problem
with my development builds, for which I use a faster but less efficient
compression for the included squashfs, so the images end up being around
1.2GiB in size. I haven't got a good sample size, but I'd say there
seemed to be a 50% chance of isohybrid making the image size not
divisible by 2048.

If it's of any help, here are some examples of development builds's
sizes before and after isohybrid post-processing:

# Example 1
Before: 1263595520
After:  1266693120 which is divisible neither by 1024^2 nor 2048

# Example 2
Before: 1309853696
After:  1316044800 which is divisible by 2048 but not 1024^2

For the record, I had lot's of images that were similar to example 1's
1263595520 bytes in size, and they all ended up as 1266693120 bytes
after isohybrid:ing them. Also note that the padding is 3097600 bytes
and 6191104 bytes, respectively.

Thomas Schmitt wrote:
> 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.

Excuse my ignorance, but you say "largest possible cylinder size". We
are not going to fill up to this theoretical maximum (our images are
currently ~910 MiB for releases, and ~1.2 GiB for development builds) so
I just want to double-check that what you propose also guarantees
divisibility by 2048 for images that doesn't fill up to this maximum.

Cheers!