Syslinux - Jan 2014 - After USB boot problems on Gigabyte GA-M55Plus-S3G

> Hi,
> 
> > The current states of each of those drives seem to suggest that, with 
> > those particular values, they would not be ideal for booting 
> > purposes.
> 
> For me as half-educated user all three would look like
> "normal" MS-DOS disks. So people buy pitfalls.
 
The filesystem might be OK, but not ideal for a broad compatibility 
for booting purposes. Factory-default settings are not necessarily 
focused on bootability.
> 
> I cannot tell whether any of the FATs uses CHS. But the
> weird H/C and S/H factors of 2 GB and 8 GB stick are
> suspicious alone.
> As said, their partition ends (LBA,C,H,S) have no integer
> solution (X,Y) of the equation
>   LBA = C * X * Y + H * X + (S - 1)
> 
> 
> > If we take the ENDing CHS values as valid:
> >  982 / 254 / 63 
> > and we calculate the corresponding LBA:
> >   ( ( 982 + 1 )
> >  x ( 254 + 1 )
> >  x ( 63 ) )
> >  - 1
> >    ___________
> >    15'791'894 
> 
> Is this calculation generally valid ? It seems to assume that
> 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
"name", if you want).

So for a geometry of Nx255x63,
1st sector: CHS: 0 / 0 / 1 = LBA 0
2nd:  CHS: 0 / 0 / 2 = LBA 1
61th:  CHS: 0 / 0 / 61 = LBA 60
62th:  CHS: 0 / 0 / 62 = LBA 61
63th:  CHS: 0 / 0 / 63 = LBA 62
64th:  CHS: 0 / 1 / 1 = LBA 63
65th:  CHS: 0 / 1 / 2 = LBA 64
126th:  CHS: 0 / 1 / 63 = LBA 125
127th:  CHS: 0 / 2 / 1 = LBA 126
189th:  CHS: 0 / 2 / 63= LBA 188
16065th:  CHS: 0 / 254 / 63= LBA 16064
16066th:  CHS: 1 / 0 / 1= LBA 16065
32130th:  CHS: 1 / 254 / 63= LBA 32129
32131th:  CHS: 2 / 0 / 1= LBA 32130
...


First, if we were talking about values higher than the CHS limit of 
1024*255*63 ( 1023 / 254 / 63 ), then every LBA value higher than 
that one is translated to that max. limit. But in this case we are 
under that max. limit.

For a CHS of " 982 / 254 / 63 ", the corresponding LBA is
15'791'894,
which means that we can count "15'791'894 + 1" sectors
starting from
"LBA 0" up to "LBA 15'791'894".

According to your report, the FAT32 volume starts at "LBA 63", the 
same as the partition as seen by fdisk, and is 15'794'113 sectors 
long, which results in 15'794'176 sectors. The last sector of the 
volume is "LBA 15'794'175".

Comparing the last sector of the FAT32 volume,
 "LBA 15'794'175",
with the last sector of the partition as seen in the partition table,
 "CHS 982 / 254 / 63" = "LBA 15'791'894"
we can see that the FAT32 filesystem limit (15'794'175) is located 
beyond the partition limit (15'791'894).

Now, you could, potentially, have a FAT32 filesystem smaller than the 
partition, but in our context the partition shouldn't be smaller than 
the FAT32 filesystem.

Maintaining the same geometry of Nx255x63, the corresponding value 
for "LBA 15'794'175" is "CHS 983 / 36 / 13".

So, the report should had said, either:
 _ End   LBA 15791894 = CHS  982 254  63
or:
 _ End   LBA 15794175 = CHS  983  36  13

> 
> It is clear that S/H must be 63 and H/C must be 255, because we
> see the maximum possible values here. (H/C could be 256. But
> that is outruled by Wikipedia about MBR.)
> 
> Nevertheless, this does not match the end LBA calculated
> from start LBA and number of blocks.
> 
> Do i miss an essential point here ?
 
Short answer:
_ unmount the partition;
_ make a backup (just in case) of the entire device using dd;
_ use fdisk (or similar) so to "create a new empty DOS partition 
table" - BEWARE: select the correct device!!! before proceeding;
_ create a new partition with STARTing offset of 2048 (or with MiB 
alignment);
_ format the partition with FAT32;
_ check the result as you did before.

Does the result make sense? Are there any error messages?

Note: some partitioning tools operate on the booting code too, not 
just on the partition table. Generally speaking, you need additional 
steps so to make the drive bootable.


> 
> 
> > If there is nothing to loose (some special feature in the USB drive, 
> > data, etc.), probably it would be best to create a new partition 
> > table, a new partition and then format them again.
> 
> Seems advisable, given the numerical madness.
> 
> This is were i see a gap in SYSLINUX wiki. The world could need
> prescriptions for a non-weird partitioning and a LBA driven
> filesystem.
> 
> While preparing an answer to Ronald, i re-read your mail of
> 17 Jan 2014 14:38:10 +0200, where you describe your test image.
> One would need to derive hands-on instructions for MS-Windows
> and Linux. (The latter might be in my reach, if i read enough
> man pages.)
 
In practical terms, create a new partition table, create one-and-only 
partition, format it, then follow the instructions from the relevant 
Live software. IMHO, for deeper troubleshooting there are forums and 
web search.
> 
> Can you sketch a prescription what a user should do to make
> an USB stick best suitable for a SYSLINUX installation ?
> 
> Currently i am unsure what in your image is experimental and
> what is recommendably traditional.
> E.g. the disabled bootable/active flag seems to be non-standard
> and we do not know for sure whether it is really needed for
> Ronald's mainboard.
 
Since the "active" flag issue was not 100% clear, and it seemed that 
his tests were more successful when the flag was not set (although 
the reason might be elsewhere), I used "altmbr.bin" (see Syslinux 
wiki).

I wouldn't consider anything in the aforementioned test.img as 
"experimental".

For most situations, using default values when creating a completely 
new partition table in modern partitioning tools should be enough.

Nowadays, I would suggest using MiB alignment (over the old 
"cylinder" alignment).

I tend to use "sectors" (not "cylinders) as units when displaying
information. Each display format has its pros and cons.

Generally speaking, nothing "bad" should happen when mixing 
partitioning tools. But if you happen to find some problem, or if you 
are not sure, I would also suggest not mixing partitioning tools. Use 
the same tool (which would rarely change its default values) for all 
partitioning tasks.
> 
> Biggest riddle for me, though, is how to achieve this with Linux
> tools and MS-Windows tools. (I know /sbin/fdisk -lu. Everything
> else i do by byte manipulations in images. Plumber style.)
> 
 
There are enough tutorials published. You can also use fdisk in 
interactive mode.

I would say that the most common mistake probably is applying the 
partitioning 
operation on the wrong device (which usually ends with data loss). 
So, 
whichever the tools, be sure to select the correct device before 
anything else 
(and people that have already suffered from this mistake might tell 
you to 
double-check the selected device before applying each operation).

Regards,
Ady.

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'794'175) is located 
> beyond the partition limit (15'791'894).
That would be ok with the LBA size of the partition,
which is exactly 15'794'175.
(This was computed from the 32-bit values out of the
 partition table: Start LBA + block count - 1.
 My values match the ones displayed by fdisk -lu)


My current theory is that vendors prefer to record
a cylinder aligned end CHS address over recording
an end CHS address which exploits the whole capacity.
This is used as an (inofficial ?) protocol to publish
the CHS factors H' and S'.

> So, the report should had said, either:
>  _ End   LBA 15791894 = CHS  982 254  63
> or:
>  _ End   LBA 15794175 = CHS  983  36  13
Yep. This is in sync with fdisk, which complains:

  Partition 1 has different physical/logical endings:
  phys=(982, 254, 63) logical=(983, 36, 13)

The theory matches with my 2 GB stick too.

Next i manipulated the 8 GB partition end CHS to be
  982 253 63
and (hoorray !) the complaint is
  phys=(982, 253, 63) logical=(987, 3, 13)
which matches
  15794175 = 987 * (253 + 1) * 63 + 3 * 63 + (13 - 1)

Finally i understand what fdisk means when it warns
about a differing "logical" ending.
It deduces the H' and S' factors from the end CHS and
then checks whether they make the end CHS match the
end LBA.

This one looks cool:
  Partition 1 has different physical/logical beginnings (non-Linux?):
     phys=(0, 1, 1) logical=(3, 0, 4)
  Partition 1 has different physical/logical endings:
     phys=(982, 3, 5) logical=(789708, 3, 1)


Have a nice day :)

Thomas

On 01/21/2014 11:13 AM, Thomas Schmitt wrote:
> 
> My current theory is that vendors prefer to record
> a cylinder aligned end CHS address over recording
> an end CHS address which exploits the whole capacity.
> This is used as an (inofficial ?) protocol to publish
> the CHS factors H' and S'.
> 
Indeed it is -- at least some BIOSes "deduce" the H/S to use from
that.

	-hpa