Loading ...
Sorry, an error occurred while loading the content.
 

RE: [partman] Changing USB Disk Geometry

Expand Messages
  • Antoine Leca
    Hi, ... Very interesting subject. I am sorry if I cannot solve your problem (since there are many details with USB sticks which are still unclear to me), yet
    Message 1 of 3 , Apr 3, 2006
      Hi,

      Thijs wrote:
      > I'm using ranish partman 2.44 to make a bootable USB stick
      > using FreeDos as OS.

      Very interesting subject.
      I am sorry if I cannot solve your problem (since there are many details with USB sticks which are still unclear to me), yet there is an immediate question:

      How do yo use PartMan with an USB stick?

      I mean, PartMan uses the BIOS Int13 interface (dated 1981). The stick uses the USB (really?) interface (dated 200x), which is based on RBC protocol, i.e. SCSI stuff, something which is NOT quite integrated in the BIOS by default.
      There are some BIOS with integrated "USB support", but there is also quite a bit of variance at this level; i.e. some just makes the stick able to boot, no more.
      To make the matter worse, the "usual" way to access USB from DOS is to use an ASPI driver, that is, exactly like some SCSI device (this makes sense given the above.)

      I am _guessing_ you configured your motherboard setup to enable USB support (HDD emulation) for the stick, then booted FreeDOS (like from floppy), and the stick was available along with the other harddisks; but I prefer to have this confirmed somewhat.


      In the following, when I write "geometry", I mean the "number of heads", "number of sectors per track", and "number of cylinders" parameters (in fact, the latter is normally computed).



      > When I partition a USB stick (1GB) in windows XP using the

      Do not make parallels here.
      Windows XP communicates with the device directly using the USB protocol, which is (sort of) LBA based. What you see as geometry is a pure chimera that XP invents to fill the holes of the backward compatibility tools which expect some numbers in some places.
      Extrapolating these number is usually a bad idea.

      > PTEDIT32.EXE:
      > Disk : 122 * 255 * 63
      > Partition : Start-CHS:0-1-1, End-CHS:121-254-63,
      > Before:63, Total:1,968,065

      1,968,065 + 63 is 1,968,128, which is above 122×255×63 (=1,959,930); I am surprised you did not got some warning here.


      > I found out that windows just uses the Before and Total
      > sector values and filles in some crap parameters for the

      Sort of, yes. Not crap, rather inexact numbers.


      > No problem, I can get it all to work fine by partitioning in
      > a DOS environment, using ranish partman 2.44.
      >
      > The thing is, when there is a windows-XP-created-partition on
      > the USB-stick, ranish will give the disk the 'windows'
      > geometry 122 * 255 * 63.

      It is not Ranish (which is clueless here). It is the BIOS emulation layer which gives these numbers.
      I guess the BIOS is making 'smart computations' based on the actual content of the partition table.
      And it seems the BIOS is not doing the work correctly/fully, furthermore...


      > When I remove the this partion and create a new one
      > using ranish the disk keeps it's 'windows' geometry, 122 *
      > 255 * 63 and makes a the following partition: Partition :
      > Start-CHS:0-1-1, End-CHS:121-254-63, Before:63,
      > Total:1,959,867 (Note the difference in sectors)

      So Partman drops the 8,198 "extra" sectors in "cylinder 122"; you are losing 4MB of capacity.

      > This partition will boot FReeDOS, but gives a warning that
      > the partion table CHS values are dubious

      Who is giving this warning, at which moment?

      > and calculates it's own values from the LBA sector data.

      Sorry, now I cannot follow you. Which LBA sector data?


      > If I reboot after removing the 'windows' partition, ranish
      > will give a different disk geometry: Disk : 976 * 32 * 63

      So *BIOS* is now indicating 1,967,616, still below the real capacity, but much nearer from the mark.


      > Finally the REAL questions:
      >
      > -How does ranish determine the disk geometry?

      It just calls BIOS.
      First it calls Int 13h AH=8 (the old way, only CHS, with the 1024 cylinder limit). Then it calls Int 13h AH=41h then AH=48h (the documented MS/IBM extension), and only pays attention to the total number of sectors (LBA), it does NOT pay attention to the geometry information returned by the same call (it is not anything special here, every other OS driver does the same, for compatibility reasons).


      > -Why does the geometry reported by ranish change?

      Because BIOS does.
      And BIOS probably does so because it tries to adjust Int 13h AH=8 guessed values with the (Windows-stamped) partition table, to aid CHS based tools like MS-DOS v.6- or old bootrecords to behave correctly.
      Remember: unlike ATA, with USB disks, there is no way (that I know of) to record any "geometry" in the device, so BIOS is required to guess it. And to add some confusion if it would a need for, there is no standard :-(.


      > -Can I FORCE the geometry to be redetermined without rebooting?

      Not that I am aware of (with RPM, unlike cheating).
      Other 'hi-tech' fdisk-like program, particularly those for Linux or *Nix do have an option to override the detected geometry (this come back from the times before the Int 13h extensions, to deal with >1024-cylinder harddisks while still using partition tables), but I do not know of such an option for RPM.

      A way to cheat, in the pure DOS-hacking way, could be to install some Int 13h AH=8 interceptor before launching RPM, and uses it to specify the geometry you want.


      > BTW:
      >
      > ==This is what my custom FreeDOS kernel reported:
      > LBA(int 13h-48h)
      > -NoCyl: 3844 (0.....3843)
      > -NoHds: 16 (0.......15)
      > -NoCyl: 63 (1.......63)

      Those three informations above are IGNORED by RPM.

      > -NoSct: 1968128 (0..1968127)
      > -NoBpS: 512
      >
      > CHS(int 13h-08h)
      > -LiCyl: 975 (976) (0..975)
      > -LiHds: 31 (32) (0...31)
      > -LiSct: 63 (63) (1...63)
      >
      >
      > ===Windows partitioning===
      >
      > -Get drive parameters
      > DrvTotSect = 1968128 (get by LBA call ??)

      Well, sort of. In fact, the RBC command set has a "number of logical blocks" field, which is probably what Windows is using (by directly querying the device).
      And since there is no counter-part "head" or "sector per track" informations, Windows has to 'guess' these latter.


      Antoine
    • Doc Chiron
      Doc Chiron here: [comments interspersed] ... as OS. ... with USB sticks which are still unclear to me), yet there is an immediate ... Doc: RPM v2.38 +up check
      Message 2 of 3 , Apr 3, 2006
        Doc Chiron here: [comments interspersed]

        >Hi, (this is Antoine)
        >Thijs wrote:
        >< I'm using ranish partman 2.44 to make a bootable USB stick using FreeDos
        as OS.

        > Very interesting subject.
        > I am sorry if I cannot solve your problem (since there are many details
        with USB sticks which are still unclear to me), yet there is an immediate
        question:

        > How do you use PartMan with an USB stick?

        > I mean, PartMan uses the BIOS Int13 interface (dated 1981).

        Doc: RPM v2.38 +up check for and use INT-13 extended calls 41 & 48 when
        available.

        > The stick uses the USB (really?) interface (dated 200x), which is based on
        RBC protocol, i.e. SCSI stuff, something which is NOT quite integrated in
        the BIOS by default. There are some BIOS with integrated "USB support", but
        there is also quite a bit of variance at this level; i.e. some just makes
        the stick able to boot, no more. To make the matter worse, the "usual" way
        to access USB from DOS is to use an ASPI driver, that is, exactly like some
        SCSI device (this makes sense given the above.)

        > I am _guessing_ you configured your motherboard setup to enable USB
        support (HDD emulation) for the stick, then booted FreeDOS (like from
        floppy), and the stick was available along with the other harddisks; but I
        prefer to have this confirmed somewhat.

        > In the following, when I write "geometry", I mean the "number of heads",
        "number of sectors per track", and "number of cylinders" parameters (in
        fact, the latter is normally computed).

        >< When I partition a USB stick (1GB) in windows XP using the

        > Do not make parallels here.
        > Windows XP communicates with the device directly using the USB protocol,
        which is (sort of) LBA based. > What you see as geometry is a pure chimera
        that XP invents to fill the holes of the backward compatibility tools which
        expect some numbers in some places. Extrapolating these number is usually a
        bad idea.

        > PTEDIT32.EXE:
        > Disk : 122 * 255 * 63
        > Partition : Start-CHS:0-1-1, End-CHS:121-254-63,
        > Before:63, Total:1,968,065

        1,968,065 + 63 is 1,968,128, which is above 122×255×63 (=1,959,930); I am
        surprised you did not got some warning here.

        Doc: It is my understanding that the BIOS HDD USB emulation mode adds an
        entry to the DISK PARAMETER TABLE (DPT) normally built by the BIOS while
        seeking out DISK DRIVES prior to booting. When found, those drives are
        interrogated to determine their capacity, LBA capability and likely their
        mfr's CHS geometry.
        When USB HDD emulation is supported, the BIOS makes similar (but USB
        compatible) interrogations and adds the values it finds to the DPT. The BIOS
        decisions about CHS translation are the likely cause of logical CHS geometry
        differences between that of the BIOS and that of Windows own drivers which
        may choose to ignore or over-ride those of the BIOS. Remember that Windows
        does NOT require that the BIOS even see or support USB hardware.

        Doc: Ever wonder where the incomplete last cylinder comes from? It's what is
        leftover after the BIOS CHS translation is performed, because the DPT
        contains both the assigned LOGICAL CHS geometry PLU the total sector count
        reported by the drive when interrogated. I believe RPM displays that partial
        cylinder based on the leftover sectors rounded to the nearest complete 63
        sector track (aka head).

        Doc: Windows has access to that same info when it interrogates a drive (USB
        or otherwise).

        >< I found out that windows just uses the Before and Total
        >< sector values and filles in some crap parameters for the

        > Sort of, yes. Not crap, rather inexact numbers.

        >< No problem, I can get it all to work fine by partitioning in a DOS
        environment, using RPM v2.44.

        >< The thing is, when there is a windows-XP-created-partition on the
        USB-stick, ranish will give the disk the 'windows' geometry 122 * 255 * 63.

        > It is not Ranish (which is clueless here). It is the BIOS emulation layer
        which gives these numbers. I guess the BIOS is making 'smart computations'
        based on the actual content of the partition table. And it seems the BIOS is
        not doing the work correctly/fully, furthermore...

        >< When I remove the this partion and create a new one using ranish the disk
        keeps it's 'windows' geometry, 122 * 255 * 63 and makes a the following
        partition:
        >< Partition :
        >< Start-CHS:0-1-1, End-CHS:121-254-63, Before:63,
        >< Total:1,959,867 (Note the difference in sectors)

        > So Partman drops the 8,198 "extra" sectors in "cylinder 122"; you are
        losing 4MB of capacity.

        >< This partition will boot FReeDOS, but gives a warning that the partion
        table CHS values are dubious

        > Who is giving this warning, at which moment?

        >< and calculates it's own values from the LBA sector data.

        > Sorry, now I cannot follow you. Which LBA sector data?

        >< If I reboot after removing the 'windows' partition, ranish will give a
        different disk geometry:
        >< Disk : 976 * 32 * 63

        > So *BIOS* is now indicating 1,967,616, still below the real capacity, but
        much nearer from the mark.

        > Finally the REAL questions:
        >
        > -How does ranish determine the disk geometry?

        It just calls BIOS.
        First it calls Int 13h AH=8 (the old way, only CHS, with the 1024 cylinder
        limit). Then it calls Int 13h AH=41h then AH=48h (the documented MS/IBM
        extension), and only pays attention to the total number of sectors (LBA), it
        does NOT pay attention to the geometry information returned by the same call
        (it is not anything special here, every other OS driver does the same, for
        compatibility reasons).


        > -Why does the geometry reported by ranish change?

        Because BIOS does.
        And BIOS probably does so because it tries to adjust Int 13h AH=8 guessed
        values with the (Windows-stamped) partition table, to aid CHS based tools
        like MS-DOS v.6- or old bootrecords to behave correctly.
        Remember: unlike ATA, with USB disks, there is no way (that I know of) to
        record any "geometry" in the device, so BIOS is required to guess it. And to
        add some confusion if it would a need for, there is no standard :-(.


        > -Can I FORCE the geometry to be redetermined without rebooting?

        Not that I am aware of (with RPM, unlike cheating).
        Other 'hi-tech' fdisk-like program, particularly those for Linux or *Nix do
        have an option to override the detected geometry (this come back from the
        times before the Int 13h extensions, to deal with >1024-cylinder harddisks
        while still using partition tables), but I do not know of such an option for
        RPM.

        A way to cheat, in the pure DOS-hacking way, could be to install some Int
        13h AH=8 interceptor before launching RPM, and uses it to specify the
        geometry you want.


        > BTW:
        >
        > ==This is what my custom FreeDOS kernel reported:
        > LBA(int 13h-48h)
        > -NoCyl: 3844 (0.....3843)
        > -NoHds: 16 (0.......15)
        > -NoCyl: 63 (1.......63)

        Those three informations above are IGNORED by RPM.

        > -NoSct: 1968128 (0..1968127)
        > -NoBpS: 512
        >
        > CHS(int 13h-08h)
        > -LiCyl: 975 (976) (0..975)
        > -LiHds: 31 (32) (0...31)
        > -LiSct: 63 (63) (1...63)
        >
        >
        > ===Windows partitioning===
        >
        > -Get drive parameters
        > DrvTotSect = 1968128 (get by LBA call ??)

        Well, sort of. In fact, the RBC command set has a "number of logical blocks"
        field, which is probably what Windows is using (by directly querying the
        device). And since there is no counter-part "head" or "sector per track"
        informations, Windows has to 'guess' these latter.


        Antoine


        --
        To unsubscribe, please, email to: partman-unsubscribe@yahoogroups.com

        Yahoo! Groups Links
      Your message has been successfully submitted and would be delivered to recipients shortly.