[syslinux] After USB boot problems on Gigabyte GA-M55Plus-S3G

[Ady]

> With respect to all of the actually important stuff however, I may have
> missed it all, but I don't recall having read or seen an explanation of
> what Ady & everybody else finally figured out about all this.  What is
> the answer, in the end?  I did get the part about how (for my board,
> at least) tweeking some of the info within the relevant MBR partition
> table entry so as to cause it to indicate/suggest LBA addressing,
> rather than CHS style addressing, is one part of what finally yielded
> success.  But what are the other parts?  I personally am still totally
> in the dark.  (This is probably my fault for not paying enough attention.)
 
There was at least one email that requested to execute some fdisk 
commands on the problematic USB drives. I don't recall having seen 
the result. Without it, we can only have an educated guess by 
carefully reading your reports.

I have mentioned this more than once already. There must be 
_matching_ values between the MBR / partition table / VBR.

For example, if the first partition starting offset is 63 sectors, 
the partition table should have CHS values that correspond to LBA 63. 
Also the FAT VBR should indicate the "hidden sectors" (aka. "sectors 
before") with a corresponding 63. If the values don't match, strange 
things will eventually happen.

Generally speaking, the BIOS itself has to support (understand) the 
values that are being used in the MBR.

With the adequate values, the MBR and the VBR still need to contain
the correct "executable" code.

If all prior steps are OK, once SYSLINUX has the control it has to be 
able to find the necessary files in the adequate location. This part 
depends on the instructions and scripts from each project, like 
Clonezilla Live for example.

But nothing of the above can happen if the BIOS settings are not 
adequate. A simple example would be: setting "HDD" as First Boot 
Priority, with the rest as "disable", and letting the BIOS find by 
itself the boot device. Since the USB devices are not included in the 
BIOS boot priority list, they can't be "automagically" found.

Simpler examples:
_ Trying to boot from a USB drive while the BIOS setting for "USB 
controller" is set to "disable";
_ Trying to boot from an IDE / PATA drive while the BIOS setting for 
the IDE controller is set to "disable".

As you can see, even with the correct bits in the USB drive, the boot 
process could fail. It would be enough to have some BIOS settings in 
a different state than what is required for the specific situation.

And we could add the need for an adequate kernel (and more) to 
support the relevant hardware...


> 
> All I know is that in the last test that Ady had me run, he had me
> creating a sort of Frankenstein-like hybrid of (a) his prior "Hello
> world" test image and (b) the 2.2.1 Clonezilla release.  Beyond that,
> I personally don't know *any* of the technical or functional details
> relating to _either_ of those two things, so I don't have any idea
> whatsoever about either (a) why Ady wanted me to do that last test or
> (b) why it seemed to boot Clonezilla OK.
 
The test.img replaced the potential "unmatching bits" in your USB 
drive. The "hello world" (which is a testing module included in 
official Syslinux which can be used by anyone) was a way to test 
whether SYSLINUX itself had a problem with your mainboard. It also 
included an adequate installation of SYSLINUX so to avoid a problem 
in Clonezilla Live's script (which is already being improved).

The first test.img proved that the USB drive can actually boot your 
mainboard, and that SYSLINUX works in it. The second test was to 
check whether Clonezilla can actually boot correctly (or if, instead, 
there are additional problems).


> 
> Is setting the partition type byte (to a value which is widely construed
> to specify/request/demand LBA rather than CHS addressing) the one and
> only tweek needed in order to get Syslinux-based stuff booting properly
> on this motherboard?  If not, then what else, exactly, is required?
> 
 
Forcing LBA for the partition type was one of several considerations, 
which might or might not had helped. I just went directly to the case 
which could, potentially, provide higher chances of initial success. 
It is most probably not necessary, if the rest of the variables are 
OK.

If we could answer what exactly makes one mainboard boot OK and the 
other to fail in just one email, then I guess that entire websites 
and forums specifically dedicated to booting issues would be almost 
never visited.

Regards,
Ady.