search for: nx255x63

...at > the end is aligned to a full cylinder. (The start is not.) Note: This is off-topic for the Syslinux Mailing List. The short answer should be: use fdisk (or similar) so to "create a new empty DOS partition table". I'll try to clarify. One thing is the CHS *geometry*, e.g. Nx255x63. But since the first LBA is 0 (zero), the first C is 0 (zero) and the first H is 0 (zero), then, for instance, "cylinder 254" is the 255th cylinder and so on. I am assuming that the CHS values that you posted are not the "amount" (Nx255x63), but the "position" (or...

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

...aybe it suffices to format the partitioned stick to a FAT > filesystem variant which uses LBA. > Let's try to avoid special or specific CHS values. Giving the recent successful tests, they seem to be not necessary. We are already seeing success when using adequate (and commonly-used) Nx255x63 values in the MBR, in the VBR, formatting as FAT32-LBA with starting offset of 2048 sectors. I would suggest keeping this format. Regards, Ady.

> 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 ingredient of the mess: a CHS driven filesystem. > > The hope with 64x32 and 255x63 is to make CHS addressing > more likely to happen correctly. Once the partition table...

...ser 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, 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 ingredient of the mess: a CHS driven filesystem. The hope with 64x32 and 255x63 is to make CHS addressing more likely to happen correctly. > So, IMHO, I don't see a Windows-user looking for mk...

> > Both sticks show very unusual factors for heads and sectors > > which are hardly intentional. If BIOS gets confused like fdisk, > > then the failure to find files is quite plausible. > > > > ------------------------------------------------------------- > > > > Could you please exercise what is described for Linux in > >

...rive, including the MBR). 3_ Use fdisk to check the geometry of the problematic drive. The geometry, instead of the previous: 22 heads, 21 sectors/track, 1016 cylinders should say: 255 heads, 63 sectors/track, 244 cylinders or: 255 heads, 63 sectors/track, 243 cylinders If the geometry is not Nx255x63, then change the "Heads" and "Sectors per Track" values to match "255" and "63" respectively. The resulting "Cylinders" value should come from the "Total sectors"/("H"x"S"), so you shouldn't need to worry about...

As I said before, booting is bigger than one bootloader. I am replying to what I think was asked. I might have misunderstood the questions. Whichever the case, this email is less about Syslinux itself. If this is considered too far off-topic in the Syslinux Mailing List, please receive my apologies. > > I still have the factory-set contents of my three USB sticks. A small

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

Hi, > I am assuming that the CHS values that you posted are not the > "amount" (Nx255x63), but the "position" The CHS values which i reported were read directly from the partition table by a hex editor. (fdisk's CHS complaints match my reading.) > "CHS 982 / 254 / 63" = "LBA 15'791'894" > we can see that the FAT32 filesystem limit (15&...

...Alignments are more about efficiency and capacity. One typical problem for users: they forget to set the partition as "active". So then they don't understand why their USB drive is not booting. In a very broad view, there are effectively two options so to improve bootability: _ Nx255x63, one-and-only partition with MiB alignment _ ZIP-like geometry, optionally / alternatively using the fourth partition only. IMHO, getting into more details with specific CHS values and examples might derail and/or discourage users, who, after all, just want to boot their USB and move on. ***...

...et of values might, perhaps, be *slightly* reduced by using the LBA code. I used FAT32 (instead of other filesystem) because of your previous reports, and because it would be a match when using partitions bigger than my 700MB test. I also forced the *same* "most-standard" CHS values, Nx255x63, on both, the MBR and the VBR of the FAT32 partition. I left no space for any other partitions by ending the first-and-only partition at the very end of the image. I used a partition starting offset of 2048 sectors and I took care that the partition table in the MBR and the VBR would use corre...

In message <73645861681468542 at scdbackup.webframe.org>, "Thomas Schmitt" <scdbackup at gmx.net> wrote: >me: >> > Check whether it fails with Clonezilla. >Ronald F. Guilmette: >> Please be specific. For Clonezilla, there are many different versions > >Any failure on the same stick which also succeeds is enough >to kill the theory of bad

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

> >Are you willing to dd such image (*not* using Windows OS) and provide > >feedback? > > Yes. More broadly, I am willing to dd and try *any* image you might > ask me to try. > Hi Ronald, You posted in a recent email in this same email thread, about successfully booting an ArchLinux USB. Among several differences in comparison to your prior tests, you used a

In message <1767645779554124797 at scdbackup.webframe.org>, "Thomas Schmitt" <scdbackup at gmx.net> wrote: >Hi, > >> > debian-7.3.0-i386-netinst.iso >> This image also boots with no problems on the GA-M55Plus-S3G. > >So isohybrid boots with and without additional GPT. >It boots with partition start 0 and with partition start at 32 kB. OK. If

...iscarding them for this mainboard and USB drives. Once this whole issue is solved, you might want to change to BIOS boot priority again according to your daily needs. *** Regarding the CHS issue, this is why my test.img used the "most-standard" values I could try as first attempt: Nx255x63 in MBR and VBR, with starting offset of 2048 for the (first-and-only) FAT32-LBA partition. Depending on your tests with it, I would had changed some parameter. Fortunately, no parameters need changing now, as your tests indicate that with such initial values Syslinux is booting correctly (reme...