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

Ady ady-sf at hotmail.com
Wed Feb 18 12:44:46 PST 2015


> [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!]
 
My guess is that the moderator allowed this email, but I do not know 
whether in addition your email address has been added to the mailing 
list. Is it?

I can cc' your email address in this occasion (which I usually would 
avoid). I do not know whether other subscribers / senders will also do 
it. In the meantime, additional replies (that were already sent, and 
future ones) can be accessed by means of the public archive (see the 
links at the end of this email).
 
> 
> 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`.
> 
 
Please be aware that genisoimage is not really maintained, and that 
there are 2 "isohybrid" tools included in Syslinux: one is a Perl 
script (older, less recommended) and one program (built from 
isohybrid.c). Additionally, xorriso builds ISO images and has optional 
isohybrid options too (there is no "post-process"). There are other 
methods, but these are the relevant ones in this scenario.

Considering the existence of alternative methods, it was important to 
clarify which of them we are talking about. Now we know :).
 
> > 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...
 
Hmm. FWIW...
951764992 / 2048 = 464729 -> correct
954132480 / (1024)^2 = 909.931... -> not a multiple of 1MiB.
Perhaps you were using a 64/32 geometry when the resulting isohybrid 
image size was a multiple of 1MiB (which would make more sense).
 
> 
> [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.
 
Generally speaking, I would say that the chances (as of version 6.03) 
of getting an isohybrid image size multiple of 2048 bytes are about %25 
for the recommended values of '-h 255' and '-s 63' and size bigger than 
1GiB. We should attempt to make it %100, even if this issue would be 
mostly relevant for virtual optical media (such as in VMs). There might 
be other important matters of influence for real HW (and we should try 
to help resolve those too), but they are not critical for _booting_.
 
> 
> 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.
 
I think that reading (some of) the prior emails in this email thread 
(see the last link in this email for the mailing list archives for 
those that you might had missed) might help. In the meantime, for a 
_max_ size of:
 1024 X 64 X 32 X 512 = 1GiB  ( > 910MiB ) 
you can use '-h 64 -s 32', and most BIOS would correctly boot (whether 
using optical media or a flash drive). Of course, you cannot truthfully 
test your development images (>1GiB) with these same parameters, so 
this is not a solution for your case.

To be clear, IM_H_O, the _user_ (in this case, TAILS' developers) 
padding with additional zeroes the resulting isohybrid image was a 
better _workaround_ than using arbitrary CHS geometries; emphasizing 
_user_ and _workaround_, not as a permanent solution in isohybrid.c.

As I said, I think the isohybrid tools should (eventually) solve the 
situation anyway.

Regards,
Ady.

PS: During the time I was writing this email, I see new emails related 
to this thread. I have not read them yet.
 
> 
> Cheers!
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> 




More information about the Syslinux mailing list