partition table entries generated for an SD-card by parted >= 1.6.23

[Michael Teichgräber]

Hello, and a happy new year to the list.

I'm using parted 1.6.2[1-5] on linux 2.4 with a quite small SD-card
in an USB card reader, visible as a scsi device. The size of the card
is 16 MB, the system reports a length of 28800 sectors, ~14 MB.

When trying to "mkpart p 1 14" after a "mklabel msdos" to get a
single partition, parted >= 1.6.23 seems to store a strange CHS-value
into the partition table entry:

    00 00 02 00 83 ca 09 01 01 00 00 00 7f 70 00 00

                   `---v--'             `----v----'
                      C/H/S = 1/202/9     length = 28799 sectors


With gdb I found that parted is using a `bios_geom' of CHS=1/255/63,
which could only cover 16065 sectors. When disk_dos.c:fill_raw_part()
is called, sector_to_chs will compute the 1/202/9-values above.
The *fdisk programs complain about it as follows:

    cfdisk -Pt :
        FATAL ERROR: Bad primary partition 0: Partition ends in the
        final partial cylinder

    sfdisk -uS -l :
        Disk /dev/sdc: 993 cylinders, 1 heads, 29 sectors/track
        Warning: The partition table looks like it was made
          for C/H/S=*/203/9 (instead of 993/1/29).
        For this listing I'll assume that geometry.
        Units = sectors of 512 bytes, counting from 0

           Device Boot    Start       End   #sectors  Id  System
        /dev/sdc1             1     28799      28799  83  Linux
                        end: (c,h,s) expected (15,154,9) found (1,202,9)



In contrast, up to version 1.6.22 the value for the partition end given
on the command line was converted within disk.c:_partition_align() to
fit into this 16065 sectors, resulting in a ~8MB large partition. In
that case the partition table entry looked like this:

    00 01 01 00 83 fe 3f 00 3f 00 00 00 82 3e 00 00

                   `---v--'             `----v----'
                      C/H/S = 0/254/63     length = 16002 sectors


It seems that a change in parted.c (from using ped_constraint_any() to
constraint_from_start_end) introduces this new behaviour. Has this
been intended? Aside from this, I wonder if the dev->hw_geom values
(CHS: 993/1/29) reported by the kernel could override the dev->bios_geom
values (255/63/1), which would produce quite good results.

Regards,
Michael