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

Hi,

Ronald F. Guilmette wrote:
> what exactly did we determine that GA-M55Plus-S3G is failing
> to support?
It appears to be related to the choice of CHS addressing with
the FAT filesystem. This opens the door for misperceived factors
of heads per cylinder and sectors per heads.

My current suspicion is that the partition end did not expose
the effective factors in its end CHS address, so that the
filesystem and the BIOS were not using the same factors.
(Alternatively the FAT system could be in sync with the exposed
 factors, but the BIOS hates them because they are neither 64,32
 nor 255,63.)

Aha, your fdisk -l results are posted now:

  ubcd.0 : Geometry: 22 heads, 21 sectors/track, 1016 cylinders
           (because end CHS is 969, 21, 21)

  oe.0   : Geometry: 151 heads, 42 sectors/track, 1021 cylinders
           (because end CHS is 92, 150, 42)

Both sticks show very unusual factors for heads and sectors
which are hardly intentional. If BIOS gets confused like fdisk,
then the failure to find files is quite plausible.

-------------------------------------------------------------

Could you please exercise what is described for Linux in
  http://www.syslinux.org/doc/usbkey.txt
and check whether
  mkdiskimage -4 /dev/sda 0 64 32
prepares a problematic stick for a normal installation of
Clonezilla, which then boots ?

This might involve the need to learn how to perform the
advised mkdiskimage run on systems other than Linux.
Such examples would be valuable for the wiki improvement.
(What is a usual address of a stick on MS-Windows ? "E:" ?)

I understand that the mkdiskimage option -4 is not what is
advised in Gene's wiki enhancement. So please also check,
whether it works without that option. 
  http://manpages.ubuntu.com/manpages/maverick/en/man1/mkdiskimage.1.html


Have a nice day :)

Thomas

> Both sticks show very unusual factors for heads and sectors
> which are hardly intentional. If BIOS gets confused like fdisk,
> then the failure to find files is quite plausible.
> 
> -------------------------------------------------------------
> 
> Could you please exercise what is described for Linux in
>   http://www.syslinux.org/doc/usbkey.txt
> and check whether
>   mkdiskimage -4 /dev/sda 0 64 32
> prepares a problematic stick for a normal installation of
> Clonezilla, which then boots ?
> 
 
I have to disagree., at least at this point.

There is no need (yet) to go looking for special CHS values. Using 
Nx64x32 geometry has its advantages, but it also has cons (and I'd 
rather not to open now an additional discussion about it).

@Ronald,

I'll start by taking the UBCD USB drive. If you have relevant data on 
it please perform a backup.

Then:

0_ BEWARE: before proceeding with each step, double-check that you 
are working on the desired device!.

1_ Check that the partition of the UBCD USB device is not mounted.

2_ zero out the first 5MiB of the drive (I am not just talking about 
the partition, but about the whole drive, including the MBR).

3_ Use fdisk to check the geometry of the problematic drive. The 
geometry, instead of the previous:
 22 heads, 21 sectors/track, 1016 cylinders
should say:
 255 heads, 63 sectors/track, 244 cylinders
or:
 255 heads, 63 sectors/track, 243 cylinders

If the geometry is not Nx255x63, then change the "Heads" and
"Sectors
per Track" values to match "255" and "63" respectively.
The resulting
 "Cylinders" value should come from the "Total
sectors"/("H"x"S"), so
you shouldn't need to worry about it. Just check that the result is 
as expected.

4_ If necessary, in fdisk change the "units" to "sectors"
(instead of
"cylinders" or whichever else).

5_ If necessary, in fdisk "toggle the DOS compatibility flag" to 
"off", so to be able to use MiB alignment.

6_ Once the geometry is Nx255x63, use fdisk to "create a new DOS 
partition table".

7_ Create a new (primary) partition.
 STARTing sector: 2048
For the END, use:
 +1908M
The "plus" sign indicates that the value is the "length" (or
"size"),
not the ending point. By adding the "M", you are saying "from the
STARTing sector, the partition size should be 1908MiB.

8_ For the newly created partition, set the partition type as FAT32, 
0x0b should be fine.

9_ Set the partition as "active".

10_ Write the partition table to disk and exit fdisk.

Before proceeding with additional steps, I would suggest "safely" 
un-mounting and disconnecting the USB drive, waiting about a minute 
and re-connecting it again. This might not be necessary under some 
OS, but it is recommended under certain circumstances / OS. Since I 
wrote the instructions in an "almost"-generic way, I'd rather add 
this note, just in case.

Please provide the new information for:
'fdisk -l -u=cylinders /dev/sdX'
'fdisk -l -u=sectors /dev/sdX'
(with the adequate "sdX")

Notes:
_ Some of the steps might not be necessary.
_ fdisk in interactive mode should be simple enough.
_ Using updated partitioning tools is, generally speaking, 
recommended.
_ It is possible that some of the steps could require using fdisk's 
eXtra functionality and then going back to fdisk's main menu.
_ BEWARE of selecting the adequate device before proceeding with each 
step.

Regards,
Ady.

> > Both sticks show very unusual factors for heads and sectors
> > which are hardly intentional. If BIOS gets confused like fdisk,
> > then the failure to find files is quite plausible.
> > 
> > -------------------------------------------------------------
> > 
> > Could you please exercise what is described for Linux in
> >   http://www.syslinux.org/doc/usbkey.txt
> > and check whether
> >   mkdiskimage -4 /dev/sda 0 64 32
> > prepares a problematic stick for a normal installation of
> > Clonezilla, which then boots ?
> > 
>  
> I have to disagree., at least at this point.
> 
I have to disagree with the disagree, at least so some extent.  I find
mkdiskimage to be an extremely useful and compact tool to do what
otherwise takes several potentially more error-prone steps.

I actually use different parameters:
	mkdiskimage -4 -z -F /dev/sdX
which is the same thing as above except using FAT32 instead of FAT16.

This has worked flawlessly with various USB thumb drives from 256 MiB to
32 GiB in size on PCs with dozens of different motherboards from about a
half-dozen different vendors.  (Actually the PCs only have one MB
each--it's the aggregation that has the dozens of MBs).

On the larger sticks I carry several versions of a number of
distributions--Clonezilla, AVG, GParted, Parted Magic, System Rescue CD,
Fedora, Centos, and several other diagnostic tools.  This gives me most
of the tools I might need, all on one or two USB sticks.

Adapting these distributions to this type of USB stick has become almost
trivial with Syslinux 6.02.  If it is of interest, I'll be glad to
provide details and step-by-step instructions.  Perhaps this type of
information could be useful somewhere in the wiki.  I'm not much of a
writer, but I'm good at step-by-step instructions.

In message <2008564557425199875 at scdbackup.webframe.org>, 
"Thomas Schmitt" <scdbackup at gmx.net> wrote:
>Ronald F. Guilmette wrote:
>> what exactly did we determine that GA-M55Plus-S3G is failing
>> to support?
>
>It appears to be related to the choice of CHS addressing with
>the FAT filesystem. This opens the door for misperceived factors
>of heads per cylinder and sectors per heads.
Assuming that is a correct analysis, one wonders who it is, exactly
that would be doing the "misperceiving".  The BIOS?
>Aha, your fdisk -l results are posted now:
>
>  ubcd.0 : Geometry: 22 heads, 21 sectors/track, 1016 cylinders
>           (because end CHS is 969, 21, 21)
>
>  oe.0   : Geometry: 151 heads, 42 sectors/track, 1021 cylinders
>           (because end CHS is 92, 150, 42)
>
>Both sticks show very unusual factors for heads and sectors
>which are hardly intentional. If BIOS gets confused like fdisk,
>then the failure to find files is quite plausible.
Would it be at all helpful for me to go back now and try to reproduce
the steps that I took/followed to create each of those two USB stick,
and then (a) report my exact steps here and (b) run the fdisk commands
again, you know, to see if they still produce the odd results?
>Could you please exercise what is described for Linux in
>  http://www.syslinux.org/doc/usbkey.txt
>and check whether
>  mkdiskimage -4 /dev/sda 0 64 32
>prepares a problematic stick for a normal installation of
>Clonezilla, which then boots ?
I'm not sure if such a test will be useful.  Quoting the document in
question:

     Some BIOSes have been reported (in particular, certain versions of
     the Award BIOS) that cannot boot USB keys in "USB-HDD" mode.

this is quite clearly *not* a problem that either I or my BIOS have.
Thus, I must ask, do you still want me to attempt this test?

If your answer is "yes", then you are going to have to help me in a
couple
of ways, specifically:

    *)  Your method of calculating number of cylinders, although explained,
        is still just slightly opaque.  Can you elaborate a bit more?  I
        do not get where the "(64*32)" part is comming from.  That
seems
        like the magician (you) just simply pulled that out of... a hat.
        Is the divisor *always* exactly 2048, i.e. 64*32 in all cases, for
        all USB drives in all systems?

     *) I mentioned before, I am not really much of a Linux guy.  So you're
        going to have to give me the proper commands (for ArchLinux
        specifically, which is what I have and what I am _almost_
        comfortable with) that will result in fetching and installing
        the two special tools called for, i.e. "mkdiskimage" and
        "syslinux".

Also, once I do all the steps in that document, should I just fetch a .zip
distribution of Clonezilla, unzip that, and then just straight copy all
the files to the prepared USB stick?
>This might involve the need to learn how to perform the
>advised mkdiskimage run on systems other than Linux.
Huh?  Why would it?
>Such examples would be valuable for the wiki improvement.
>(What is a usual address of a stick on MS-Windows ? "E:" ?)
As I mentioned earlier, I actually greatly prefer *not* to work on Windows,
you know, if I can get the same task done under e.g. FreeBSD.

To answer your question about Windows however, there *is* no "usual"
drive letter for _anything_ (as far as I know) on Windows... except
for (a) the first floppy drive and (b) the second floppy drive and
(c) the Windows boot partition.

A Short Description of Drive Lettering on Windows
-------------------------------------------------

    By tradition, left over from ancient (MSDOS) times, the letters A:
    and B: are resevered, and will refer to your one or two floppy drives,
    if present.   If either or both are not present, then the letters A:
    and/or B: are _still_ reserved anyway, will simply not be used.
    
    When Windows sees a new device containing a partition of a type it
    understands (FAT or NTFS) then it will assign that partition the next
    available unused drive letter.  Thus, the Windows boot partition is
    almost always C:.  The next Windows-understood partition becomes D:
    and so on, for the first device, until all of the Windows-understood
    partitions on the first-seen device have been lettered.  Then we go
    on to the second, third, forth, etc. devices, and assign each of the
    Windows-understood partitions on each of those the next available
    letter... E:, F:, G:, ... and so on.
    
    There are two caveats to the above simple description.
    
    First, a given Windows-understood partition may be manually assigned
    a specific (not-currently-used) letter by the system administrator.
    When this is requested, in effect the partition is unmounted from
    Windows and then re-mounted as the specific requested letter.  And
    the newly assigned letter for the given partition is "sticky" with
    respect to that partition.  If you take the device, physically dis-
    connect it, and then attach it to some different Windows system, it
    will still show up as the same letter it was hard-assigned to back
    on the original system.  (And also, if you just leave it attached to
    the original system, but you power cycle that system, when the system
    comes back up, the given partition will still show up as having the
    same specific drive letter that the system administrator assigned to
    it before the machine was power cycled.)
    
    The second caveat is that Windows shares (network shared directories)
    which can be... and normally are... reactivated automagically each
    time the using user logs back in, get assigned a letter by the user
    explicitly when the given share is first attached.  And if that user
    then logs off and logs back in, then (barring any conflicts) that same 
    share will show up again for that same user as the same drive letter
    it had that last time that user was logged in.

(Note:  I am *not* really a Windows guy, so take everything I've said
above with a grain of salt.  This is just my understanding of how drive
letters are assigned, based on my limited experience.)


Regards,
rfg

Hi,

Ady:
> > > I would suggest not using the work "disk".
me:
> > I am unhappy with "disk" too.
> > But that change would have a much wider scope in the text.
Ady:
> You can still use a different wording in a linked section. If
"disk"
> is not the best choice for the new section, then choose a better 
> term.
Two problems:

There are probably reasons why "disk" was chosen as term for
the wiki. I am reluctant to overthrow this choice without
backing from SYSLINUX developers.

What term to use instead of "disk" ?
"Drive" might be more modern, but an USB stick is not actually
a drive. "Device" is probably a unixism and also anbigous,
because partitions are devices, too.

Finding a new term and getting agreement is worth a separate
wiki overhaul project.

> > > It [SYSLINUX] works on GPT too.
> > This is hopefully a feature, not a problem. :o)
> Yes, my point is that a casual user might (mis)interpret (from 
> certain paragraphs) that Syslinux is for MBR only.
This is an interesting wiki enhancement project, too.
Starting at the statement on the main wiki:
"prepare a normal MS-DOS formatted disk".

First one would have to collect tangible information.
(I know GPT as i know MBR: on byte level only.)


Have a nice day :)

Thomas

Hi,

Ronald F. Guilmette wrote:
> one wonders who it is, exactly
> that would be doing the "misperceiving".  The BIOS?
I would assume so. But one will have to check out the source
code of SYSLINUX or ask Peter Anvin about this.

> Would it be at all helpful for me to go back now and try to reproduce
> the steps that I took/followed to create each of those two USB stick,
For my wiki enhancement project, it would be interesting
to see whether SYSLINUX tool mkdiskimage can bring the stick
into a state that is suitable for a SYSLINUX based installation.
E.g. Clonezilla.

Telling from the existing documentation i would try this
on a Linux system, if the stick is larger than 1 GiB:

  mkdiskimage -F /dev/sdX 0 255 63

(With /dev/sdX being the proper device address.)

If you can heal the stick, then you may next try to find out
how it got ill.

> Some BIOSes have been reported (in particular, certain versions of
> the Award BIOS) that cannot boot USB keys in "USB-HDD" mode.
Yours can. Ady's test image does not bear a ZIP-disk layout.

> If your answer is "yes",
Yes, it is. For the wiki.

> Your method of calculating number of cylinders, although explained,
> is still just slightly opaque.
"Slightly" is a slight understatement. It is obscure.
I don't think that it is the SYSLINUX wiki job to tell how
to program a correct partitioning tool. My plan is to just
state a few geometries which - by SYSLINUX developers - are
repeatedly mentioned as best practice.

E.g. i got the "64x32 or 255x63" prescription first from Peter Anvin,
when i implemented isohybrid production in xorriso.

> Is the divisor *always* exactly 2048, i.e. 64*32 in all cases, for
> all USB drives in all systems?
64x32 is recommended for disks or images <= 1 GiB.
Above that limit, the cylinder address would become larger
than 1023, which is the limit that can be stored in the
Cylinder fields of a MBR partition table.

255x63 reaches that limit shortly before a size of 8 GiB.

For sizes above, CHS has only ornamental value ... i hope.

> Is the divisor *always* exactly 2048, i.e. 64*32 in all cases, for
> all USB drives in all systems?
It is chosen by the partitiong tool and it seems convention
to publish the factors in the H and S values of end CHS.
(Ady's image did not follow that convention, though.)
 
> Also, once I do all the steps in that document, 
With mkdiskimage it reduces to

* Make sure to operate on the disk which you want to equip with SYSLINUX.

* Make a backup of the disk content. It will be gone after this procedure
  is done.

* Run mkdiskimage

The first two steps are not actually in the scope of SYSLINUX.
But i mention them, because of the possibly high level of
adrenaline in the blood of the reader, when she/he is looking
for reasons of failure.

> >This might involve the need to learn how to perform the
> >advised mkdiskimage run on systems other than Linux.
> Huh?  Why would it?
In case you want to do it on FreeBSD or MS-Windows. It's up to you.
I would like to see non-Linux examples which are confirmed to work.

> To answer your question about Windows however, there *is* no
"usual"
> drive letter for _anything_ 
The question was rather whether the proper argument for mkdiskimage
on MS-Windows would be a drive letter "X:" or something else.

Or whether mkdiskimage is supposed to work on MS-Windows at all.
(I am quite confident with FreeBSD, because there i'd try /dev/da0.)


Ady wrote:
> > If a user doesn't know what "create a new DOS partition
table" means,
> > there are many ways to find out, including a web search.
Ronald F. Guilmette wrote:
> I know what it means, but I have (at least) three different ways to
> do it that I can think of right off the top of my head,
That's why i want to show some tangible examples.
The main wiki shows installation instructions for "NT/2K/XP",
"DOS", "Linux". Best would be to have examples for all
those.

> My point is that just commanding a user to "create a new DOS partition
> table" may not be sufficiently specific to achieve the desired result,
> as some or all of these tools may perhaps be creating partitions in
> a manner that is incompatible... with some thing or another.
That's why i want to show mkdiskimage examples after having
told the users that they may use their usual partition tool.

> In fact, the more I think about it, the more I think that it is
> rather entirely ill-advised for Clonezilla to have four different
> recommended install procedures for Windows and an additional three
> different procedures for Linux.
I agree.
But that is really out of the scope of SYSLINUX.

My excuse as Clonezilla developer would probably be that
for any image there is a mainboard which lets it fail.
Another excuse is that Clonezilla development does not
know the size of your target device. So an image will
probably waste some GB if not adjusted by partition editing.

But hey. I am here because i help producing ISOLINUX images.
I am all in for images.

> Nor should any such ordinary end-luser
> ever feel the need to look at ANY PART of the Syslinux Wiki.
That's an important point when judging the scope of wiki
articles.
The SYLINUX wiki is for people who install SYSLINUX and some
self-chosen (Linux) kernel with its associated files.

It shall also give hints (not complete explanations) what
might have gone wrong if booting fails.
I try to enhance it in respect to disk layout.
As Ady stated, there are many other portential reasons for
failure. (This is stated now in my wiki sketch.)

> The way to make all of this stuff maximally simple for real end-lusers
> (including me) is for the Syslinux project to STRONGLY suggest to its
> direct user base that they all make it a point to distribute simple,
> pre-partitioned, pre-formatted dd-able images.
If the SYSLINUX developers agree, then this could be stated
prominently at the web site and in the documentation.
But i would expect that several SYSLINUX users step up and
tell why they cannot follow this advise.


Have a nice day :)

Thomas

On 01/22/2014 02:57 PM, Ronald F. Guilmette wrote:
> 
>> Could you please exercise what is described for Linux in
>>  http://www.syslinux.org/doc/usbkey.txt
>> and check whether
>>  mkdiskimage -4 /dev/sda 0 64 32
>> prepares a problematic stick for a normal installation of
>> Clonezilla, which then boots ?
> 
> I'm not sure if such a test will be useful.  Quoting the document in
> question:
> 
>      Some BIOSes have been reported (in particular, certain versions of
>      the Award BIOS) that cannot boot USB keys in "USB-HDD" mode.
> 
> this is quite clearly *not* a problem that either I or my BIOS have.
> Thus, I must ask, do you still want me to attempt this test?
> 
> If your answer is "yes", then you are going to have to help me in
a couple
> of ways, specifically:
> 
>     *)  Your method of calculating number of cylinders, although explained,
>         is still just slightly opaque.  Can you elaborate a bit more?  I
>         do not get where the "(64*32)" part is comming from. 
That seems
>         like the magician (you) just simply pulled that out of... a hat.
>         Is the divisor *always* exactly 2048, i.e. 64*32 in all cases, for
>         all USB drives in all systems?
> 
No.  The 64x32 happens to be the numbers used by the Iomega Zip drive,
and a lot of early USB BIOS support code was really written for
zipdrives more than for hard drives, which weren't commonly available in
the USB flavor back then.

As such, 64x32 seems to be the numbers that work best on some number of
systems, followed by 255x63 which are simply the largest possible
numbers and thus very commonly used for actual hard disks.

	-hpa