Syslinux - Jan 2014 - After USB boot problems on Gigabyte GA-M55Plus-S3G

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

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

Anecdotally:

dd if=/dev/zero of=binary.img bs=1M count=500
mkfs.vfat binary.img
syslinux binary.img
mount binary.img /mnt
cat > /mnt/syslinux.cfg <<EOF
DEFAULT linux
LABEL linux
LINUX /boot/bzImage
APPEND root=/dev/sda1 init=/bin/ash
EOF
umount /mnt
kvm binary.img

An unpartitioned hard disk image formatted with vfat is fairly simple.
But I absolutely understand this developer-slamming-their-head-against-desk
feeling. The above is the only formula that helped relieve that for me. By
giving me a control environment to test against. Though I am eager to try
this `mkdiskimage' now that it has been brought up.

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