[syslinux] After USB boot problems on Gigabyte GA-M55Plus-S3G
Ady
ady-sf at hotmail.com
Mon Jan 20 16:41:17 PST 2014
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.
More information about the Syslinux
mailing list