GNOME Bugzilla – Bug 657088
Wrong device information
Last modified: 2011-08-28 17:17:26 UTC
For a 16 GB USB-stick, GParted displays the following: Partitiontable: msdos Heads: 255 Sectors/Track: 63 Cylinders: 1948 Sectors: 31301631 Sector size: 512 ... results in: 255 * 63 * 1948 = 31294620 So I guess, the correct values are: Cylinders: 1949 Sectors: 31301632 For a 16 GB USB-stick, containung Ubuntu Live, GParted displays the following: Partitiontable: msdos Heads: 64 Sectors/Track: 32 Cylinders: 15283 Sectors: 31301631 Sector size: 512 ... results in: 64 * 32 * 15283 = 31299584 So I guess, here the correct values are: Cylinders: 15284 Sectors: 31301632
After adding a 3.73 GiB partition (3820 MiB, cylinder aligned) partition info is: First sector: 63 Last sector: 7823654 Sectors total: 7823592 As sectors are always counted from 1, the following should be more correct: First sector: 64 Last sector: 7823655 Sectors total: 7823592
GParted uses the sector numbering scheme from parted. Hence it will report the same numbers as parted does. The values for Cylinders/Heads/Sectors (CHS) are generally no longer valid for today's hard drives. See http://en.wikipedia.org/wiki/Cylinder-head-sector for more information. It is certainly valid for the two USB sticks to have two different sets of "spoofed" CHS values. In fact if you erased the stick that has a first sector of 64 and 32 sectors/track, and then created a new partition table using GParted or Parted, you would most likely find that the sectors/track changed to 255. The CHS values are generally used by legacy operating systems, such as DOS.
By "no longer valid" I mean that the CHS do not correspond to the physical disk properties. In the case of a USB stick, there is not even a spinning disk drive. :-)
First I must admit, that there are 2 "typos" in my report: - Both outputs from bug descrition refer to the same USB stick, where the first one results from a partitioning from GParted. - In comment 1 you should resd "After creating a ..." (the original partition was erased). Thanks for your detailed info, but all about CHS I knew before and ... > has a first sector of 64 and 32 sectors/track IMHO this is not possible, as there is no field for sectors/track in the MBR's partition table. The value is guessed from the start sector of the first partition, here 64, which is believed as the 1st sector of a track, minus one. > sectors/track changed to 255 This is too not possible, as there are only 6 bits in CHS to determine the sector, referring the wikipedia article, counting from 1 to 63. No matter, if the CHS values don't matter in modern BIOS, IMHO they should be consistent, e.g. for DOS usage, and displayed as such by GParted. If parted is the source of those bad values, so please forward the bug to there. Note: I have investigated a deeper look by a hex editor on block device level. It addresses from 0 to 3BB3FFDFF, which indeed calculates to 31301631 sectors, so the last track in a 32 sectors/track scheme is incomplete and has only 31 sectors, but IMO it is more intuitive to even count incomplete cylinders and tracks.
Since CHS stuff is really only relevant to legacy operating systems, this is not a concern for modern operating systems. As such I do not plan to spend any time on this issue myself. If this problem bothers you the please feel free to raise it with the parted team. Parted bugs can be reported at bug-parted@gnu.org.
The CHS stuff seemed relevant to me, as I had problems with Windows XP, reading this GParted tweaked USB-stick. It only saw the 1st shrinked Ubuntu partition starting at sector 33, but not the 2nd NTFS-Partition, so I checked for all possible reasons. See Bug 657118. Now I know, that Windows can only read the 1st partition of a "removable media". If the USB-stick is recognized as a hard disk, Windows will read all partitions, so I'm wondering, why it didn't work, as GParted said: Media byte 0xf8 (hard disk) I've reported the problem to parted bug list.