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

> >Are you willing to dd such image (*not* using Windows OS) and provide 
> >feedback?
> 
> Yes.  More broadly, I am willing to dd and try *any* image you might
> ask me to try.
> 
 
Hi Ronald,

You posted in a recent email in this same email thread, about 
successfully booting an ArchLinux USB. Among several differences in 
comparison to your prior tests, you used a different USB drive.

I have uploaded a gzipped image, to be expanded and dd'ed to the USB 
drive that you were using for your former tests. This way you keep 
your USB drive with ArchLinux available, and we can keep comparing 
against your previous results.

The image I have uploaded is for testing purposes only. Once 
extracted from the gzip archive, you get a 700MB test.img to be dd'ed 
to your USB device.

The image includes a bootable MBR code ("altmbr.bin" from Syslinux), 
no "active" partition is set, one FAT32 (LBA) partition with a 
bootable SYSLINUX VBR, and some Syslinux c32 modules in it. Booting 
it, should show the Syslinux version, a "hello world" message and the 
Syslinux boot prompt.

Please avoid using Gparted or any other partitioning tool at this 
opportunity. Just expand the image, dd it to the USB device (I mean, 
to the "whole" USB device, not just to the current partition of the 
USB device) and try booting the problematic system with F12 during 
POST.

If the boot fails, I would suggest changing the order of the BIOS' 
"boot priority" settings.

According to your feedback, we'll see how to move forward.

The image is already available for download, and will remain 
available for the next 7 days.

NAME: test.img.gz
SIZE: 1'435'616 bytes
MD5 : 07A4FFC69CA51CA24D43F793E9FE8529
SHA1: 4845AB7D15994DA3EAD05DF39BDA8C4E96304328

Download (because of the email formatting, you might see the code 
distributed in more than one line): 
http://www.fileconvoy.com/dfl.php?id=g11bb56c955445d469994445242cd49ee
fb24db36f 

Please let us know how it goes.

Regards,  
Ady.

In message <BLU0-SMTP286922092D88A4C62E4A95F8BB90 at phx.gbl>, 
Ady <ady-sf at hotmail.com> wrote:
>You posted in a recent email in this same email thread, about 
>successfully booting an ArchLinux USB. Among several differences in 
>comparison to your prior tests, you used a different USB drive.
Well, yes.  I probably should not have confused the issue with that
change, but for the record, I have no reason whatsoecer to even vaguely
suspect that any of the various USB stick I have here are in any way
defective.
>I have uploaded a gzipped image, to be expanded and dd'ed to the USB 
>drive that you were using for your former tests. This way you keep 
>your USB drive with ArchLinux available, and we can keep comparing 
>against your previous results.
I have no critical need for ArchLinux on a USB stick, so that is neither
here not there.  And in any case, I can always just dd it again to any
one of my many USB sticks as and when the need arises.
>Please avoid using Gparted or any other partitioning tool...
Oh you can bet that I *will* avoid using any such tools!

(That's part of why I was so insistant on getting images that I could
just dd to the USB stick(s)... far less chance for me to mess up the
process somehow, you know, on my end.)
>NAME: test.img.gz
>SIZE: 1'435'616 bytes
>MD5 : 07A4FFC69CA51CA24D43F793E9FE8529
>SHA1: 4845AB7D15994DA3EAD05DF39BDA8C4E96304328
Hope you don't mind too much.  I actually didn't bother to check the
checksums.

Anyway, I did fetch the file, unzipped it, and then dd'd
"test.img" to
_both_ my 4GB Transcend _and_ also to my 8GB Patriot.    (I used bs=1m.
I assume that's OK.)

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?


Regards,
rfg


P.S.  Of course, during all of this experimentation, I have been messing
around a lot with the BIOS settings, but really only the ones relating to
specifying the general classes of boot devices (e.g. floppy, CD/DVD,
Hard Disk, USB-HDD, for 1st, 2nd, 3rd) and also the separate Boot Priority
list.

Because of my fiddling with those things, I was just slightly worried that
perhaps I had ... somewhere along the line... adjusted one of those BIOS
setting in a way that suddenly made _everything_ work, and that possibly
this could be the reason that various stuff... including ArchLinux,
Debian, and your test image... were booting OK now.  So just in case,
an without changing *any* settings, I went back to my original three
USB sticks that contain (1) Clonezilla and (2) Ultimate Boot CD, and
(3) OpenELEC to see if any of those would in fact boot now.

The answer is a resounding NO!  Those three still do not even want to
show up in this board's Boot Priority list.  And as tech support from
Gigabyte informed me awhile ago, if the thing doesn't show up in that
list then there is no way that the board is even going to try to boot
from the thing in question.

I am just relating these additional facts so that you'll be sure (as I
now am) that the non-booting problems on this board seem most definitely
*not* to be attributable to me just simply having goofed the BIOS settings
earlier on.  Translation:  There apparently *are* booting issues with
this board, some of which at least, cannot simply be attributed to an
RFG brain fart.  (For the record, I _have_ been known to have brain farts
from time to time, but this isn't one of them, I am relieved to say.)

Hi,
> I have no reason whatsoecer to even vaguely
> suspect that any of the various USB stick I have here are in any way
> defective.
Yeah. But can that "8GB Patriot" show the failure
when you put one of originally failing systems onto it ?
You mentioned Clonezilla, UBCD, OpenELEC.

> Anyway, I did fetch the file [Ady's FAT32 image],
> unzipped it, and then dd'd "test.img" to
> _both_ my 4GB Transcend _and_ also to my 8GB Patriot.
> [...] _does_ appear to boot OK [...]
So my suspicion against FAT turns out to be as wayward
as it felt. Probably just some deceiving coincidence.

The only plausible theory in my mind would be that one
of your USB sticks does not work well with that single
mainboard.
But if the Patriot can fail or succeed at will, then
i am clueless. (One could mumble about old, meanwhile
fixed bugs in SYSLINUX.)


Have a nice day 

Thomas

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