> Hi, > > Ronald F. Guilmette: > > > Doesn't the Syslinux project provide (hopefully strong) specific > > > reccomendations, [...] > > hpa: > > We try (see our wiki), > > The general wiki > http://www.syslinux.org/wiki/index.php/SYSLINUX#Creating_a_Bootable_Disk > says > "In order to create a bootable disk using SYSLINUX, prepare a normal > MS-DOS formatted disk." > which would not have helped me to avoid Ronald's problem. > I would have considered any existing FAT as "normal". > > Maybe one should add a link to a new section > "Possible pitfalls of MS-DOS disk partitioning and formatting" > in > http://www.syslinux.org/wiki/index.php/Common_Problems > > It would give an overview or links about "partitioning", "filesystem", > "FAT", "LBA", and "Cylinder/Head/Sector". > Then it would advise Ady's layout of LBA driven FAT32 with > conservative partitioning. > > > I would volunteer as half-educated author of such a section, > but possibly i am already too much spoiled by detail knowledge. > Does anybody know comprehensive existing user documentation about > the topic, to which the wiki could link ? > (Wikipedia is too detailed and scattered to be of help during a > computer crisis. See > http://en.wikipedia.org/wiki/Master_boot_record > http://en.wikipedia.org/wiki/File_Allocation_Table > ) > > > Maybe one should also swap the positions of the links on the > left edge of the general wiki: > "Help" > http://www.syslinux.org/wiki/index.php/Help:Contents > and > "Common Problems" > http://www.syslinux.org/wiki/index.php/Common_Problems > because most users would seek help with boot problems, rather > than help with editing the wiki. > > > Have a nice day :) > > ThomasIn a certain way, the problem is never-ending. For instance, the (U)EFI standard is about a decade (or more) in the making, and it is not stable / consistent enough yet. Another one: for years the whole "booting with USB drives" was, from the point of view of the final user, almost an "art" of trial an error between CHS geometry, USB-HDD, USB-FDD, USB-ZIP,... A USB drive would work in one BIOS version, and after a BIOS update it would not; or it would work in one system but not in the other. By the time we finally have a more-or-less "commonly-used" "well-known" "most-frequently-working" quasi de-facto so-called "standard values", we start again, this time with UEFI. The whole "booting business" is bigger than one specific bootloader. Saying that there are more than just a couple of articles about booting would be laughable. There are entire websites and forums dedicated just to booting. IMHO, there is more-than-enough to do about The Syslinux Project itself, including improving documentation for versions 4.xx and 6.xx. Distros and other similar "live" projects are constantly trying to improve bootability, as much as their resources allow, because they want their users to be able to use their software. Regarding contacting / improving other projects mentioned in this email thread, there is already work in progress, at least about part of them. I should say this is an ongoing effort, almost always. BTW, in retrospect, the issues in this whole email thread were less related to formatting a filesystem, and more about using adequate _matching_ values between BIOS, partition table and VBR. Regards, Ady.
Thomas Schmitt
2014-Jan-20 13:02 UTC
[syslinux] After USB boot problems on Gigabyte GA-M55Plus-S3G
Hi, Ady wrote:> The whole "booting business" is bigger than one specific bootloader.Too many participants at too many interfaces.> IMHO, there is more-than-enough to do about The Syslinux Project > itselfNevertheless i believe that the SYSLINUX wiki could be more tangible about what is a "normal" MS-DOS formatted disk. At least for those who seek help for their troubles. I still have the factory-set contents of my three USB sticks. 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. Have a nice day :) Thomas
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.