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

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 observation: producers of USB drives care about sales :). 
Since most USB drives are used for goals other than booting, 
generally speaking the partitioning and formatting factory-set 
details are focused on parameters such as speed and disk capacity.

Having a different CHS (among other details) can add some additional 
capacity. This additional usable space could be considered as 
"derisory" or "irrelevant in practical terms", but it could
also be
seen as good publicity when common (non-technical) people compare 
products to decide their next buy.

Sometimes, the specific CHS values come from some "template" image 
dd'ed to the device. If the image was created by certain software 
that uses different CHS values according to the resulting size, this 
"default" value is used on the USB device; that's all.

So in some cases, having special CHS values, or special features 
(like some "password protection" partition), are a plus for USB drive 
producers, but they might also reduce the chances of being used as 
bootable media in certain systems.

If the USB drive works for its current goal (which might not involve 
booting), that's fine. If the device is intended to be the boot media 
for one particular system and it is successful in doing so, that's 
fine too. But if the goal is to be used as booting media for a 
variety of different systems, then improving the chances of booting 
turns to be an important feature. If that's the case, a new 
partitioning scheme might help.

> 
> Maybe you can tell which of them would be a pitfall for Ronald's
> board:
> --------------------------------------------------------------
> 
> 2 GB Intenso:
> Partition type  0x06  (Wikipedia: FAT 16, CHS or LBA)
> Start LBA       32 = CHS    0    1   1
> End   LBA  3915775 = CHS  956  128  32
> The latter has no integer solution pairs for H/C and S/H. 
> (Neither have neighboring LBAs.)
> Partition content according to command "file":
>   x86 boot sector, Microsoft Windows 98 Bootloader IO.SYS+MSDOS.SYS,
>   code offset 0x3c, OEM-ID "MSWIN4.1", sectors/cluster 64, root
entries 512,
>   Media descriptor 0xf8, sectors/FAT 239, heads 128, hidden sectors 32,
>   sectors 3915744 (volumes > 32 MB) , serial number [...], unlabeled,
>   FAT (16 bit)
> 
> --------------------------------------------------------------
> 
> 4 GB Sandisk with U3 CD-ROM emulation:
> Partition type  0x0b  (Wikipedia: FAT32, CHS or LBA)
> Start LBA       38 = CHS    0   0   39
> End   LBA  7839719 = CHS  487 254   63
> Integer solution pair at:  H/C= 255  S/H= 63
> Partition content according to command "file":
>   x86 boot sector
>   (There are several sectors which end by the MBR signature 0x55 0xaa.
>    If i cut off the first 38 * 512 bytes then Linux mount recognizes
>    it as "vfat".)
> 
> --------------------------------------------------------------
> 
> 8 GB Corsair:
> Partition type  0x0b  (Wikipedia: FAT32, CHS or LBA)
> Start LBA       63 = CHS    0   1   1
> End   LBA 15794175 = CHS  982 254  63
> The latter has no integer solution pairs for H/C and S/H. 
> Partition content according to command "file":
>   x86 boot sector, code offset 0x58, OEM-ID "MSDOS5.0",
sectors/cluster 8,
>   reserved sectors 36, Media descriptor 0xf8, heads 255, hidden sectors 63,
>   sectors 15794113 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 15394,
>   serial number [...], unlabeled
> 
> --------------------------------------------------------------
> 
> The two partitionings without integer (H/C,S/H) cause complaints
> by fdisk about differing "physical/logical endings".
> The CHS values which i read by hex editor match those of "phys".
> No idea from where fdisk gets the "logical" ones.
> 
 
The current states of each of those drives seem to suggest that, with 
those particular values, they would not be ideal for booting 
purposes.

Of course they might boot "as-is". I can only make some generic 
observations.

Regarding the U3 4GB drive, it seems to be not specially design as a 
bootable device. If you buy a USB drive with special features, 
wouldn't you want to actually take advantage of them?

Regarding the "physical/logical" difference, generally speaking there 
are several possible reasons. Sometimes it just indicates that the 
partition does not start / end at a cylinder boundary, typically in 
old versions of fdisk (and similar old partitioning software).

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.

Regarding the 2GB drive, note that it is using a FAT16 filesystem 
with 64 sectors per cluster. Depending on the typical size of the 
files you save in it, it could waste a lot of space. It seems as a 
Win98 bootloader (as if you were booting to a Win98 DOS prompt from a 
normal IDE HDD). Depending on the type of usage for this USB drive 
and depending on which OS needs access to the files, it could be 
alternatively formatted as FAT32 (in addition to creating a new 
partition table mentioned before).

For this 2GB drive, the ENDing CHS values seem strange to me. Since 
LBA, Cylinders and Heads are counted starting from zero, I would have 
expected the ENDing CHS for the partition to be 955x127x32 (not 
956x128x32). Perhaps this is the source of the "physical/logical 
ending" discrepancy shown by fdisk.

For the 8GB drive, it seems to be using quite common CHS values, 
except for the "physical/logical" discrepancy.

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 

Since the CHS geometry is smaller than the limit of
 1024x255x63 ( 1023 / 254 / 63 ), 
then the reported ENDing LBA of 15'794'175 should not have been 
bigger than the calculated value. This might be the reason for the 
"physical/logical" discrepancy.

Regarding the FAT32 filesystem in this 8GB drive, note that it is 
"CHS or LBA", type 0x0B. So the CHS values could be used in some 
cases, which means that adequate CHS values are necessary.

Also note that the starting offset of the partition is 63 sectors (as 
in common non-flash HDD devices), which is not a multiple of 4. 
Creating a new partition table and using a STARTing offset of 64 
might improve its speed and/or useful life. Using a STARTing offset 
of 2048 would improve compatibility with some partitioning tools.

@Thomas, If this email doesn't answer your questions, I hope at least 
might be 
helpful anyway.

Regards,
Ady.

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.

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

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 ?

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

> @Thomas, If this email doesn't answer your questions, I hope at least 
> might be helpful anyway.
You were very helpful with this issue. Thanks a lot.
I was not even aware that there are CHS FAT and LBA FAT.

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.

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


Have a nice day :)

Thomas

On 01/21/2014 12:22 AM, Thomas Schmitt wrote:
> 
>> 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.)
It isn't.  To calculate the LBA from an arbitrary CHS address when the
geometry is C':H':S':

LBA = (C * H' * S') + (H * S') + (S - 1)

or equivalently

LBA = ((C * H') + H) * S' + S - 1
> 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 ?
I think the essential point is that the CHS geometry offered on the
preformatted stick seems to be "impossible".  Most likely the
manufacturer simply did not care.

Consider this:

8 GB Corsair:
Partition type  0x0b  (Wikipedia: FAT32, CHS or LBA)
Start LBA       63 = CHS    0   1   1
End   LBA 15794175 = CHS  982 254  63

If LBA 63 = CHS 0/1/1 then we know S'=62, but that is completely
inconsistent with the ending sector being 63.  In other words, the CHS
information in this partition table is complete garbage.
>> 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.
Fortunately geometry is becoming a fading problem.  We're dealing with
an old board and BIOS here.
> 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.)
	-hpa

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