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

Ady
Sat, 18 Jan 2014 06:25:10 -0000

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