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

[Ronald F. Guilmette]

In message <BLU0-SMTP1383C5798F6C577E5FFF368BA40 at phx.gbl>, 
Ady <ady-sf at hotmail.com> wrote:

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

If there is still information you need in order to fully get to the
bottom of this case, PLASE let me know what else you still need.

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

Hummm... I had to go a Googling' to find out what "VBR" stands for.
But now I know.  (I _always knew that there was _something_ special
at the start of every partition, but I never knew what it was called
until now.)

>For example, if the first partition starting offset is 63 sectors, 
>the partition table should have CHS values that correspond to LBA 63. 

I _think_ that I _perhaps_ understand what you just said.

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

OK.  Are you saying that this critical matchup was NOT present in or on
the originals Clonezilla, UBCD, and OpenELEC USB sticks that I had in my
possession before I started this whole thread?  You know, the ones that
booted find on other machines (but not on the GA-M55Plus-S3G) ?

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

Yes.  But what exactly did we determine that GA-M55Plus-S3G is failing
to support?

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

Yes, but I assume that was all OK at the outset, because again, those
three sticks were booting up just fine on other machines... just not
on the GA-M55Plus-S3G.

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

Check.  Understood.

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

I never had either of those problems.

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

Right.

You have been very good and through in answering and describing all of
the many things that _could_ go wrong or that _might_ go wrong in
different situations & cases.  And I thank you for that.  But my
question was more specific:  Have we determined what actually *did*
go wrong, in my case?  I mean yes, I admit that early in this thread
I may perhaps have posted some info or test results that might possibly
have been either misleading or outright incorrect, due to my lack of
clear understanding the exact/true semantics of the various boot-
related setting in my BIOS, but I feel that I have a crisp and clear
understanding of those now, have confugured those properly now, and
yet two of the three USB sticks that I started with ... the two that
I did now overwrite during the course of these investigations...
*still* do not boot on the GA-M55Plus-S3G but still *do* boot on
other machines I own.  So what exactly and specifically is ``wrong''
with those two sticks (which contain UBCD & OpenELEC)?  That was my
question.

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

So to be clear, you are affirmatively asserting that Clonezilla (2.2.0
and also 2.2.1) contains problematic "unmatching bits"?  Which bits
exactly?  Do we know?  The "hidden before" number in its VBR is
different than where the Clonezilla partition actually ends up?

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

So the question is:  Do we know, specifically, what ``brokenness''
existed/exists within Clonezilla that your test.img components
replaced/overrode. you know, in order to make the thing work in the
end?

>Forcing LBA for the partition type was one of several considerations, 
>which might or might not had helped.

Is it worthwhile to conduct one more test in order to find out if that
part helped or made no difference?

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

I am asking the more limited question:  What do we now know, specifically,
that causes this board (GA-M55Plus-S3G) to *not* boot sticks that other
systems happily boot.

Sometimes it is easiler to explain & describe failure than it is to
explain & describe success.

I couldn't even begin to explain eveything that went into us getting to
the moon in 1969, however I can say... as others have... that the tragic
Apollo 1 fire was caused by the presence of pure oxygen in the capsule...
and some stray spark.


Regards,
rfg