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

[Ady]

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