similar to: isohybrid and ISO images whose size is not a multiple of 2048 bytes vs. VirtualBox

> Hi, > > at [Tails] we're in the process of shipping hybrid ISO images by > default again. We're using `isohybrid -h 255 -s 63' to do that (thanks > to the advice we got on this mailing-list a few months ago!). > > And then, we've discovered that sometimes, isohybrid produces ISO > images whose size is not a multiple of 2048 bytes. > > Who cares?

Hi, Ady wrote: > Let's not forget that the goal usually is to select CHS values so that > the resulting (optical and/or other) media would boot correctly in as > many systems as possible Agreed. But we now have a report about failure of 255x63 on a popular pseudo-hardware, when the ISO is presented as DVD-ROM. (Probably there is no complaint when it gets presented as hard disk.)

[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 >

Hi, > Hopefully I am explaining it better this time. Our ideas of implementation are supposed to yield the same result. As said, i am willing to implement my proposal in a copy of isohybrid.c, if somebody wants to test it. Advantages and disadvantages should be obvious. Interested users please send util/isohybrid.c from your local SYSLINUX source code installation to me. Just to be sure

> Hi, > > > Hopefully I am explaining it better this time. > > Our ideas of implementation are supposed to yield the > same result. > Hmm, I am not sure. Or perhaps I am misunderstanding your code. Let me try with an example (or two). For this example, let's assume: -h 255 -s 63 ISO size: 1'085'736'960 bytes ( > 1GiB) This size happens to be a

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

> 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. And my suggestion to modify the _amount_ of Cylinders was intended to overcome the "by 4" (or rather, "by

Hi, my proposal is based on a mathematical proof (see mail before) and yours is correct too. They cannot but match. Let's inspect your examples: Ady wrote: > ISO size: 1'085'736'960 bytes ( > 1GiB) This are exactly 132 cylinders of 255x63. 132 is divisible by 4. So there is no padding needed. > Cylinders (1st attempt)=132 > [...] > 2120580 / 4 = 530145, so

> > Same result as yours. > > > Have a nice day :) > > Thomas > I was under the impression (apparently the wrong one) that your pseudo-code was adding 4 cylinders to the first example, from 132 to 136, which would be non-optimal. Since I am not a developer, I believe you when you say that such jump won't happen :). Perhaps the code will be more clear to me

> 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. > > > The workaround cannot be temporal, because the

> > I wrapped the essential code into a standalone program for > playing with a few numbers: What about '-h 255 -s 63 , ISO size 1085736960' ? > I expect the average waste to be a bit less than 16 MB. Yes, but slightly misleading. For example, the "16MB average" is relevant for 255/63. Some user reading the code might not know the whole reasoning for: >

Hi, > Now, I have a question: what about the "offset" parameter? How it > modifies our assumptions and calculations if the "offset" parameter is > not zero? The offset influences only the start address of the partition. The alignment goal is about the end address. So these concepts are nearly independent. Of course, partition start must be smaller than partition

Hi, intrigeri wrote: > We're using `isohybrid -h 255 -s 63' [...] > isohybrid produces ISO > images whose size is not a multiple of 2048 bytes. Seems to be intentional. http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/utils/isohybrid.in # Target image size: round up to a multiple of $h*$s*512

Hi, it would be interesting to know for what solution TAILS decides and whether any problems arise with it. ------------------------------------------------------- On with the fundamental discussion of MBR cylinders: Ady wrote: > 1_ The resulting ISO9660 file system size shall be a multiple of 2048 > (bytes_per_sector). The known ISO production programs comply to this condition.

Hi, Ady wrote: > my suggestion to modify the _amount_ of Cylinders was intended to > overcome the "by 4" (or rather, "by 2048") issue. Now i get your intention. You want to align the resulting ISO to 4 full cylinders in order to avoid the need for a cylinder size divisible by 4. This would work. But with -h 255 -s 63 it could waste up to 32,899,072 bytes. >

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

> 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

> Hi, > > it would be interesting to know for what solution > TAILS decides and whether any problems arise with it. > > ------------------------------------------------------- > On with the fundamental discussion of MBR cylinders: > > Ady wrote: > > 1_ The resulting ISO9660 file system size shall be a multiple of 2048 > > (bytes_per_sector). > >

Hi, > What about '-h 255 -s 63 , ISO size 1085736960' ? -h 255 -s 63 , ISO size 1085736960 : align_factor= 4 , padding= 0 , image size= 132.000000 cylinders ----------------------------------------------------------------- Code of isohybrid_test_mockup.c : ----------------------------------------------------------------- #include <stdlib.h> #include <stdio.h> int

> Hi, > > Ady wrote: > > my suggestion to modify the _amount_ of Cylinders was intended to > > overcome the "by 4" (or rather, "by 2048") issue. > > Now i get your intention. You want to align the > resulting ISO to 4 full cylinders in order to avoid > the need for a cylinder size divisible by 4. > No :). I want to align to resulting