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

> 
> You will be happy to know that your test image _does_ appear to boot OK
> on my GA-M55Plus-S3G, from either/both of my test sticks (4GB & 8GB).
> 
> Whatever magic you did, it seems to have worked.  (Please _don't_ go
> into too much technical detail, but... in layman's terms... what did
> you do?)
> 
> Here is what I got after booting from the 8GB Patriot:
> 
>     SYSLINUX 6.03 EDD 6.03-pre1 ...
>     Hello, world, from 0x0037C210! malloc return 0x0037d850
>     boot:
> 
> and then the cursor just sat blinking, in the second column following
> the "boot:"
> 
> I assume this indicates success, yes?
> 
 
OK then, we are making progress.

I would like to ask you to keep the current BIOS settings without 
changes, at least for now. Whichever the current settings are, you 
are having more successful results than before.

 *** 

Regarding your question about what I did with the test.img (which 
might be of interest to others), I just took your own reports and 
avoided the potential problems as much as I could.

By using "altmbr.bin" (included in Syslinux), we don't have to
care
about the "active" flag (I am avoiding the technical details about 
how to use it). There is no partition flagged as "active".

I also "forced" a FAT32 LBA filesystem, although normally a partition 
of 700MB would not require such conditions. The potential influence 
of a "not-nice" (in the eyes of this BIOS) CHS set of values might, 
perhaps, be *slightly* reduced by using the LBA code. I used FAT32 
(instead of other filesystem) because of your previous reports, and 
because it would be a match when using partitions bigger than my 
700MB test.

I also forced the *same* "most-standard" CHS values, Nx255x63, on 
both, the MBR and the VBR of the FAT32 partition.

I left no space for any other partitions by ending the first-and-only 
partition at the very end of the image.

I used a partition starting offset of 2048 sectors and I took care 
that the partition table in the MBR and the VBR would use correct 
matching values.

I also installed SYSLINUX in the adequate directory, where Clonezilla 
*should* be installing it (Clonezilla Live 2.2.1-22 is not choosing 
the best location for 'ldlinux.sys').

I used 700MB so you could, potentially, be able to at least copy to 
that partition some additional files for further testings.


 *** 

Now, to move forward with Clonezilla in your USB drive, we need to 
proceed with some steps that are not as simple as dd'ing an image.

After dd'ing my test.img to the USB drive, you would have one FAT32 
partition of about 700MB. So:

1_ Expand the content of the Clonezilla Live zip archive in some 
temporal directory.
2_ Move *almost* all the resulting expanded content from the temporal 
directory to the FAT32 partition in the USB drive; with the 
*exception* of the following directories (and their contents, of 
course):
2a_ './isolinux/'
2b_ './syslinux/'

Note that my test.img already contains a './syslinux/' directory with 
some files in it.

3_ Move (part of) the content of Clonezilla's temporal './syslinux/'
directory to the equivalent './syslinux/' directory located in the 
FAT32 partition in the USB drive, with two *caveats*:

3a_ If the filename already exists in the destination directory, 
*keep it*, do *NOT* replace it with the one from Clonezilla. This is 
specially important for './syslinux/ldlinux.sys'.

3b_ The only file from Clonezilla's temporal directory that indeed 
should replace the one already placed in the USB drive is 
'./syslinux/syslinux.cfg'.

The result should be a "mix" of Clonezilla files and the boot code 
already in place in my test.img.

I hope I was clear enough in the above instructions, as it would be 
relatively easy to confuse which files should be copied and 
overwritten and which files shall not. If something is not clear, 
just ask.

Then boot the USB drive (using F12 during POST as before). I would 
expect at least the initial Clonezilla boot menu to show up.

According to your feedback, we'll take the next step.

Regards,
Ady.

On Fri, 17 Jan 2014, Ady wrote:
> Regarding your question about what I did with the test.img (which
> might be of interest to others), I just took your own reports and
> avoided the potential problems as much as I could.
>
> By using "altmbr.bin" (included in Syslinux), we don't have
to care
> about the "active" flag (I am avoiding the technical details
about
> how to use it). There is no partition flagged as "active".
>
> I also "forced" a FAT32 LBA filesystem, although normally a
partition
> of 700MB would not require such conditions. The potential influence
> of a "not-nice" (in the eyes of this BIOS) CHS set of values
might,
> perhaps, be *slightly* reduced by using the LBA code. I used FAT32
> (instead of other filesystem) because of your previous reports, and
> because it would be a match when using partitions bigger than my
> 700MB test.
>
> I also forced the *same* "most-standard" CHS values, Nx255x63, on
> both, the MBR and the VBR of the FAT32 partition.
>
> I left no space for any other partitions by ending the first-and-only
> partition at the very end of the image.
>
> I used a partition starting offset of 2048 sectors and I took care
> that the partition table in the MBR and the VBR would use correct
> matching values.
Could that be a problem with a very strict BIOS implementation?  It's 
not an even multiple of CHS values, like 2079.

(I have not been following this thread too closely, so may have missed 
some details.)

In message <BLU0-SMTP2805E16A0E7A33B925EDF458BB80 at phx.gbl>, 
Ady <ady-sf at hotmail.com> wrote:
>Now, to move forward with Clonezilla in your USB drive, we need to 
>proceed with some steps that are not as simple as dd'ing an image.
Apologies for my impertinence, but I have one question:  Why?

I was under the impression that we had reached an agreement under
which _you_ would perform all necessary bit-fiddling... insuring that
all steps are down exactly as you think best... and that THEN you would
give me an image that I could simply dd to a stick and try.  Did we not
agree upon that?

I am not trying to be difficult. I am genuinely concerned that there
will be some small/obscure aspect of one or more of the steps you ask
me to do in preparing a USB stick for the next desired test that I
will inadvertantly/unintentionally phuck up.  In this area, you are
the expert, and you know what you are doing, whereas with respect to
all of this booting & BIOS stuff, my ignorance asymptotically approaches
infinity.

I will send you an off-list e-mail, following this one, where I will give
you directions to a writable FTP directory on my server where you can
place test images for me to try (using dd).  (Or alternatively, you may
continue to place them elsewhere and then send me links.)
>I hope I was clear enough in the above instructions, as it would be 
>relatively easy to confuse which files should be copied and ...
This is my point.  You gentlemen have all been most kind and diligent
in pursuit of answers to these problems.  I don't want to be responsible
for screwwing up some small aspect of the next desired test, and thus
wasting your time with meaningless or misleading test results produced
from a test that I have screwed up somehow.
>Then boot the USB drive (using F12 during POST as before).
To be clear, I *have not* been using F12 during POST for any of my recent
tests.  There has been no need to do so.

In the case of the tests that have performed where there has been success
in booting, I have _only_ had the test USB stick attached, and no other
sticks or drives attached to the system, and the (successful) stick does
show up...  as the *only* listed item... in the BIOS Boot Priority list.
Thus, it is unnecessary to go into the BIOS boot menu, because the BIOS
is seeing one and only one attached bootable device, so it just attempts
to boot that device.

In the case of the tests that have performed where there has been failure,
the test stick does not, in general, even show up in the BIOS Boot Priority
list, so the BIOS never even attempts to boot the thing.  (In some cases
there has been a failure when the stick *does* show up in the Boot Priority
list and *after* the SYSLINUX banner has been printed, but I have been
diligent in describing and reporting those.)

If you think that it would help somehow for me to be making explicit boot
device selections using F12 then I will do so, in future.


Regards,
rfg

> 
> In message <BLU0-SMTP2805E16A0E7A33B925EDF458BB80 at phx.gbl>, 
> Ady <ady-sf at hotmail.com> wrote:
> 
> >Now, to move forward with Clonezilla in your USB drive, we need to 
> >proceed with some steps that are not as simple as dd'ing an image.
> 
> Apologies for my impertinence, but I have one question:  Why?
> 
> I was under the impression that we had reached an agreement under
> which _you_ would perform all necessary bit-fiddling... insuring that
> all steps are down exactly as you think best... and that THEN you would
> give me an image that I could simply dd to a stick and try.  Did we not
> agree upon that?
> 
> I am not trying to be difficult. I am genuinely concerned that there
> will be some small/obscure aspect of one or more of the steps you ask
> me to do in preparing a USB stick for the next desired test that I
> will inadvertantly/unintentionally phuck up.  In this area, you are
> the expert, and you know what you are doing, whereas with respect to
> all of this booting & BIOS stuff, my ignorance asymptotically
approaches
> infinity.
> 
> I will send you an off-list e-mail, following this one, where I will give
> you directions to a writable FTP directory on my server where you can
> place test images for me to try (using dd).  (Or alternatively, you may
> continue to place them elsewhere and then send me links.)
> 
> >I hope I was clear enough in the above instructions, as it would be 
> >relatively easy to confuse which files should be copied and ...
> 
> This is my point.  You gentlemen have all been most kind and diligent
> in pursuit of answers to these problems.  I don't want to be
responsible
> for screwwing up some small aspect of the next desired test, and thus
> wasting your time with meaningless or misleading test results produced
> from a test that I have screwed up somehow.
> 
> >Then boot the USB drive (using F12 during POST as before).
> 
> To be clear, I *have not* been using F12 during POST for any of my recent
> tests.  There has been no need to do so.
> 
> In the case of the tests that have performed where there has been success
> in booting, I have _only_ had the test USB stick attached, and no other
> sticks or drives attached to the system, and the (successful) stick does
> show up...  as the *only* listed item... in the BIOS Boot Priority list.
> Thus, it is unnecessary to go into the BIOS boot menu, because the BIOS
> is seeing one and only one attached bootable device, so it just attempts
> to boot that device.
> 
> In the case of the tests that have performed where there has been failure,
> the test stick does not, in general, even show up in the BIOS Boot Priority
> list, so the BIOS never even attempts to boot the thing.  (In some cases
> there has been a failure when the stick *does* show up in the Boot Priority
> list and *after* the SYSLINUX banner has been printed, but I have been
> diligent in describing and reporting those.)
> 
> If you think that it would help somehow for me to be making explicit boot
> device selections using F12 then I will do so, in future.
> 
> 
> Regards,
> rfg
 
I'll try to reply here to your last series of emails in this email 
thread. Although this may disrupt the different conversations, in 
this particular occasion I'd rather write once and (try to) make some 
coherent sense.

Apologies for the long email. I am trying to cover different aspects 
with some hope that eventually it might result useful to other users 
with similar issues.

 *** 

The reason I asked you to use F12 to select the USB device is because 
I am trying to "skip" at least *some* potential difficulties with the 
BIOS boot priority settings (among others). And since some mainboards 
can list some USB drives as "HDD" instead of "USB-HDD"
during the
boot selection, I am trying to avoid some BIOS decisions. By using 
F12, you can try several times to re-boot the same USB drive and 
search the list of boot devices, instead of partially relying on 
other BIOS settings such as boot priority.

For these tests, I would recommend setting the BIOS boot priority to 
"USB-HDD" as first boot device and "HDD" as second (and
probably
"disable" any other). And yet, for testing purposes I would still 
suggest going through F12, specially when some first test failed to 
boot the USB drive. If the first "automatic" boot failed, then reboot 
and use F12. If that fails, reboot and try F12 again, selecting a 
different category of boot type device.

Although there are additional boot device options such as "USB-FDD" 
and others, I am currently discarding them for this mainboard and USB 
drives.

Once this whole issue is solved, you might want to change to BIOS 
boot priority again according to your daily needs.

 *** 

Regarding the CHS issue, this is why my test.img used the 
"most-standard" values I could try as first attempt: Nx255x63 in MBR 
and VBR, with starting offset of 2048 for the (first-and-only) 
FAT32-LBA partition. Depending on your tests with it, I would had 
changed some parameter. Fortunately, no parameters need changing now, 
as your tests indicate that with such initial values Syslinux is 
booting correctly (remember the Syslinux version and copyright 
message included "EDD" when booting the USB drive with my test.img).

 *** 

Since you reported already being able to successfully boot this 
system with USB drives that were previously failing, I am discarding 
(for now) the possibility of a corrupt hardware (mainboard, USB 
drives, USB ports...).

 *** 

Not all USB ports are the same. For instance, in some mainboards the 
USB ports at the front of the computer case might be not recommended 
for booting purposes. At least for these tests, I would suggest to 
use always the same USB port where you have already seen success.

For these tests, plug in just one USB drive, to the same USB port 
where you already succeeded. Keep other USB ports empty, and 
unnecessary drives disconnected (if possible).

Once the current goal is accomplished, feel free to use other USB 
ports for booting or for whatever else.

 *** 

Regarding some recent comments about using GParted Live, let me 
clarify that it is an excellent tool and that my prior suggestion for 
not using it was intended for "just for the moment". Since _you_ are 
making all these tests, while receiving different types of 
suggestions to go different ways, my intention was to avoid using 
different tools that act on the MBR.

Different partitioning tools may have different "default" settings. 
In combination with different BIOS, we could go back to the initial 
CHS issues, or other unintended consequences.

Using partitioning tools such as GParted might also alter the current 
MBR, depending on which action you apply. Since I provided a specific 
MBR ("altmbr.bin", first-and-only partition, no "active"
flag, no
remaining space) with specific values for the partition table, my 
suggestion not to use "GParted or any other partitioning tool at this 
opportunity" was intended towards keeping the test "intact". It
is
the only way as to reduce potential unwanted interactions from 
different partitioning tools.

For example, the partition starting offset I used for my test.img was 
2048, but some partitioning tools might change the value to 63 (or to 
others), depending on the user's options. I was trying to avoid this 
type of problem.

But this does not mean that GParted is not good, or that you should 
not use it at all. If we know which values are successful, and which 
booting code works for you, we can go back and use GParted (or any 
partitioning tool that matches your needs).

 *** 

Many partitioning tools are not capable of writing actual booting 
code to the MBR. GParted can set the "active" (aka "boot")
flag, but
the booting code that GParted can write in the MBR is just "dummy", 
not bootable.

Some users think that they can just use the GParted program so to 
make a USB drive bootable. By itself, it can't. An "actual"
booting
code for the MBR is not provided by GParted.


 *** 

Regarding the use of Windows, I can understand that you are not so 
comfortable with it. There is one advantage when using Windows in our 
current context: the Windows-based SYSLINUX installer can do certain 
things in one single command while the Linux-based SYSLINUX 
installers can't. This is also true the other way around; it just 
happens that the Windows-based SYSLINUX installer might be convenient 
for this particular case, while under Linux we need additional 
commands / steps / writing.

 *** 
>From your own reports, I am confident that you don't need to keep 
trying different ISO images, dd'ing some additional distro, expanding 
additional archives.

The initial problem has nothing to do with UBCD, nor Clonezilla Live, 
nor OpenELEC, nor... The problem is related to using an adequate 
partitioning (one) and a formatting tool (one), with the adequate 
values, together in combination with adequate BIOS settings.

Mixing different partitioning tools (with different behaviors and 
default values) might sometimes corrupt the boot code or a mismatch 
between actual partitions and the partition table.

This particular mainboard might be using different BIOS values than 
others, and there are several other alternative explanations for all 
these issues. Your last few tests suggest that we are on a good track 
now.

 *** 

Regarding my last instructions (instead of "just dd'ing"), there
are
several reasons.

I have my own resources' limitations. Preparing special images with a 
size of several GB and uploading them in hopes they will work as 
expected is beyond my current possibilities.

I am trying to be careful when writing instructions. I could make 
some mistake, or miss some step, but I am trying not to. If they are 
not clear enough, just ask.

If you were to follow my instructions and you make some mistake or 
something goes wrong or the instructions are not clear, all you would 
have to do is to dd my test.img again and ask for directions.

Actually following my last instructions would take you a few minutes, 
much less than preparing, uploading and downloading images.

By writing instructions, they might be helpful to others too, in the 
event they find some similar issues.

And more importantly, you (should) want to be able to eventually do 
it yourself, for whichever version of Clonezilla or any other tool, 
(over)writing any USB drive. These testing procedures are *not* going 
to be necessary in the future, once you know how to format the USB 
drives in a way that "just works".

I would like to ask from you to _at least try_ my last instructions. 
They are about copying certain directories and files to your USB 
drive, overwriting certain files while not overwriting others. Use 
whichever OS you like.

For convenience (and to avoid potential misunderstandings), I am 
repeating the text down here.

 *** 

After dd'ing my test.img to the USB drive, you would have one FAT32 
partition of about 700MB. So:

1_ Expand the content of the Clonezilla Live zip archive in some 
temporal directory.

2_ Move *almost* all the resulting expanded content from the temporal 
directory to the FAT32 partition in the USB drive; with the 
*exception* of the following directories (and their contents, of 
course):
2a_ './isolinux/'
2b_ './syslinux/'

Note that my test.img already contains a './syslinux/' directory with 
some files in it.

3_ Move (part of) the content of Clonezilla's temporal './syslinux/'
directory to the equivalent './syslinux/' directory located in the 
FAT32 partition in the USB drive, with two *caveats*:

3a_ If the filename already exists in the destination directory, 
*keep it*, do 
*NOT* replace it with the one from Clonezilla. This is specially 
important for 
'./syslinux/ldlinux.sys'.

3b_ The only file from Clonezilla's temporal directory that indeed 
should 
replace the one already placed in the USB drive is 
'./syslinux/syslinux.cfg'.

Then boot the USB drive (using F12 during POST as before). I would 
expect at 
least the initial Clonezilla boot menu to show up.

 *** 

Please let us know how it goes.

Regards,
Ady.