Playing around with things a bit, it seems that fdisk and sfdisk strongly
encourage C/H/S geometry, while parted is quite happy with arbitrary resolution.
 The big catch is that parted uses *inclusive* arithmetic, and arguably
incorrectly, for sizing the end of a partition.  For example:

parted -s /dev/sda mkpart primary 1 2

Will create a partition whose first sector is at precisely 1 MiB and whose last
sector is at precisely 2 MiB.  If you want to do it right, you need to set "unit
s" in parted and subtract 1 from the end address.  For example:

parted -s /dev/sda unit s mkpart primary 128 204927

Will create a partition that is precisely 100 MiB in size, 64 KiB aligned, just
after the MBR and partition table, assuming 512 byte sectors.

It should be noted that some SANs present 2048 byte sectors to the OS, and 4096
byte sectors will soon be standard, so the sector size and precise sector count
should be read explicitly.

Since my python sucks, but I needed arbitrary precision integer math to handle
large volumes, I developed a shell front-end and python back-end to create
partitions of specified sizes (plus using the rest in a final partition, so
specifying no sizes uses the whole disk) with the specified alignment.  I have
used these successfully in %pre on a test system.  Please consider these
examples only.  This was my first complete python script.

#!/bin/bash
# partalign.sh
# front-end to partalign.py

if [ $# -lt 2 ]; then
        echo 'usage:'
        echo 'partalign.sh device align_kiB [part1_MiB...]'
        exit 1
fi

DEVICE=$1

dd if=/dev/zero of=$DEVICE bs=4k count=4k
parted -s $DEVICE mklabel msdos

SECTOR_B=$(parted -s $DEVICE unit B print | grep -F Sector | cut -d ' ' -f 4 |
cut -d B -f 1)
TOTAL_S=$(parted -s $DEVICE unit s print | grep -F Disk | cut -d ' ' -f 3 | cut
-d s -f 1)

python partalign.py $SECTOR_B $TOTAL_S "$@"

#!/usr/bin/python
# partalign.py

import os
import sys

def dopart(dev, part, start, end):
        rc = os.spawnvp(os.P_WAIT, "parted", ("-s", dev, "unit", "s", "mkpart",
part, str(start), str(end)))
        if rc != 0:
                sys.exit(rc)

if len(sys.argv) < 5:
        print("Not enough arguments")
        sys.exit(1)

sector_b = long(sys.argv[1])
total_s = long(sys.argv[2])
device = sys.argv[3]
align_kb = long(sys.argv[4])

if align_kb <= 0:
        print("Invalid alignment")
        sys.exit(2)
elif align_kb > 1024:
        print("Alignment too large")
        sys.exit(3)

align_s = (align_kb * 1024) / sector_b

# truncate the slack, and remember that parted uses inclusive addressing
last_s = (total_s - (total_s % align_s)) - 1

# leave plenty of room for mbr, partition table, etc.
reserve_kb = 64

reserve_s = (reserve_kb * 1024) / sector_b
while reserve_s < align_s:
        reserve_s *= 2

start_s = reserve_s

parttype = "primary"
count = 0
args = range(len(sys.argv))
for i in args:
        if i < 5:
                continue
        count += 1
# do we need an extended partition?
        if count == 4:
# use the full physical space, so the slack can be used later
                dopart(device, "extended", start_s, total_s - 1)
                count += 1
                start_s += reserve_s
                parttype = "logical"
                continue
# linux only supports 15 partitions per disk
        elif count == 15:
                break
        if sys.argv[i] <= 0:
                break
        part_mb = long(sys.argv[i])
        part_s = (part_mb * 1024 * 1024) / sector_b
# end_s is inclusive
        end_s = start_s + part_s - 1
        if (end_s > last_s):
                break
        dopart(device, parttype, start_s, end_s)
        start_s += part_s

# if there's any room left, use it
if start_s <= last_s:
        dopart(device, parttype, start_s, last_s)

Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.

If this bug still exists in rawhide, please change the version back to
rawhide.
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)

Thanks for your help and we apologize for the interruption.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Does this problem remain true for Fedora 9?

Does this problem remain true for RHEL-5.3?