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

Ronald F. Guilmette rfg at tristatelogic.com
Wed Jan 22 14:57:18 PST 2014


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


More information about the Syslinux mailing list