search for: 255x63

...ition. Not overly unhealthy, i'd say, because the ISO filesystem still fits into the partition. Nevertheless not totally clean. Does fdisk -lu complain ? An alternative would be to request a cylinder size which is divisible by 2048. E.g. isohybrid -h 252 -s 63 The cylinder sizes 64x32 and 255x63 emerged as best candidates when we compared our collections of questionable experience and rumors. More substance is not to see behind them. (Actually Cylinder/Head/Sector addressing is so brain damaged that only ill firmware can insist in it having a particular form. All sane firmwares will simp...

> An alternative would be to request a cylinder size which > is divisible by 2048. E.g. > > isohybrid -h 252 -s 63 > > The cylinder sizes 64x32 and 255x63 emerged as best > candidates when we compared our collections of questionable > experience and rumors. More substance is not to see behind > them. > (Actually Cylinder/Head/Sector addressing is so brain > damaged that only ill firmware can insist in it having > a particular form...

Hi, me: > > But MiB alignment does not match 255x63 cylinders. (Or at least > > only in very large steps. They share no prime factors except > > the block size.) Ady: > It doesn't matter. My test.img for Ronald had Nx255x63 geometry, and > STARTing LBA of 2048. Yeah. It has end CHS 89,69,35. But it lacks the other ingredien...

> Hi, > > me: > > > But MiB alignment does not match 255x63 cylinders. (Or at least > > > only in very large steps. They share no prime factors except > > > the block size.) > > Ady: > > It doesn't matter. My test.img for Ronald had Nx255x63 geometry, and > > STARTing LBA of 2048. > > Yeah. It has end CHS 89...

...gt; "active". So then they don't understand why their USB drive is not > booting. Ok. This is now mentioned in User:Scdbackup#New_Common_Problems_Bad_Heritage_on_MS_DOS_disk > In a very broad view, there are effectively two options so to improve > bootability: > _ Nx255x63, one-and-only partition with MiB alignment I hope for the partitioning tools to guide the user. But MiB alignment does not match 255x63 cylinders. (Or at least only in very large steps. They share no prime factors except the block size.) > _ ZIP-like geometry, optionally / alternatively usin...

...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 edi...

> 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

...rs. > > > > 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. My suggestion considers whichever pair of H*S (Cylinder _size_) values (which are command-line parameters), so there is no contradiction between my suggestion and recommended...

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: > 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.) We do have statements by hpa that cylinder geometry can matter. But actually i am not aware of a particular example, from which we could judge whether 255x63 is...

Hi, Ronald F. Guilmette wrote: > what exactly did we determine that GA-M55Plus-S3G is failing > to support? It appears to be related to the choice of CHS addressing with the FAT filesystem. This opens the door for misperceived factors of heads per cylinder and sectors per heads. My current suspicion is that the partition end did not expose the effective factors in its end CHS address, so

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

Just a small correction: Thomas Schmitt via Syslinux <syslinux at zytor.com> wrote: > > > 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. > > We advise two geometries: -h 63 -s 32 and -h 255 -s 63. > isohybrid behavior with the first one will not

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, > > 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, > > > 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, 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 the answer is "yes". My calculation gets align_factor = 4. So isohybrid would pad up to quadruple cylinders. Well, 132 is already such a quadruple. > W...

...r should avoid playing with individual values for START, length or END of partitions or filesystems. The common user should set a "commonly-used" geometry in fdisk (or similar), and maintain it. Let me put it this way, for a user having problems with the partitioning scheme: 1_ Use Nx255x63 geometry in fdisk 2_ create new partition table 3_ create new partition 4_ format. 5_ move on to whatever you want to do. I already posted in a prior email about 10 or so steps for Ronald, with more details, in a more-or-less generic style. This is what user-friendly partitioning tools are doing...

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? ... may you ask. Well, apparently, VirtualBox does:

Hi, Ady wrote: > I would suggest adding an internal link to respctive sections of the > wiki, not more text in the same page. This is reasonable. Please have a look at http://www.syslinux.org/wiki/index.php/User:Scdbackup The first section shall become the new text of http://www.syslinux.org/wiki/index.php/SYSLINUX#Creating_a_Bootable_Disk The second section shall become a new