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

Ady ady-sf at hotmail.com
Tue Jan 21 15:14:39 PST 2014


> 
> 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.
 
As I wrote already, we don't really "need" more information. At some 
point I offered to continue with some additional steps, so to make 
your USB drives bootable in the future, with their full capacity, on 
your own control about what "Live" system to put in there. It's up to 
you. The code in Syslinux won't gain anything, just you.

> 
> >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) ?
 
We have no specific information about those USB drives (not even an 
"fdisk -l" and similar commands), and we don't know exactly which 
BIOS settings were used in each test. We also don't know how exactly 
you wrote those USB drives with the specific tools (UBCD, etc.).

In addition, The Syslinux Projext doesn't write the code for the BIOS 
of any of the tested mainboards.

If we have to go one item at a time so to eliminate it from the 
potential culprits, we could be writing long emails for several more 
weeks.

So, what exact combination is/was making this mess?; we don't know. 
We do know that using adequate BIOS settings and an adequate 
partition scheme, it boots.

> 
> >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?
 
We don't have information about the failing USB drives, and we don't 
know which BIOS settings are/were being used.

> 
> >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.
 
Well, initially, the USB drives were still partially booting. At some 
point, they stopped *at all*. Remember my expression "We seem to go 
backwards". Assuming that the USB drive is still in the same 
condition (and assuming no "wear out" is part of the problem), then 
the BIOS settings changed during your tests.

So, again, your other systems might have different BIOS settings, or 
their BIOS versions might be more tolerant or flexible for different 
CHS values, or... See my point?

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

I am going to repeat what Genec requested at some point. Please post 
the result of (replace 'sdX' with the adequate device):

 'fdisk -l -c=dos -u=cylinders/dev/sdX' 
and
 'fdisk -l -u=sectors /dev/sdX' 

where 'sdX' is (are) the problematic device.


> 
> >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?
 
We would be assuming. We don't know how some potential mismatch value 
got in there. There are too many "unknowns".

> 
> >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?
 
Only partially. But whatever could be incorrect in those USB drives, 
we can't blame it entirely on any particular "Live" software 
(Clonezilla, UBCD,...). In fact, currently there is no proof that any 
one of them had something to do with the issue.

> 
> >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?
 
Regarding that detail in particular, currently I would say it is not 
worth it, IMHO. But if you want to at least provide the result of the 
aforementioned 'fdisk' commands...

> 
> >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.
> 
 
If you want to provide the result of the fdisk commands, perhaps we 
can eventually know what exactly is wrong; no promises. More 
importantly, eventually you might be able to actually use those USB 
drives again, without having to wonder whether they might stop 
working in some additional system, or whether some data in them might 
be lost.

Regards,
Ady.



More information about the Syslinux mailing list