Re: v3.0: scripting, args, boundaries

[Jim Meyering]

Neal Murphy wrote:
> I'm trying to use parted 3.0 (and recently 2.3) as part of a scripted Linux
> installation. And I have encountered no end of obstacles. It won't work no
> matter what I try.
>
> Where's the 'force' option, to make parted take the specified action no matter
> how much it wants to prevent me from doing what I want to do? 'mklabel gpt'
> either insists on asking me if I'm sure or won't take the action.

Thanks for all the feedback.  Sorry you find it frustrating.

Please list the precise commands you're using.
I seem to recall that this usually works:

    parted -s /dev/XXX mklabel gpt

However, if in doubt (maybe some previous partition table
is causing trouble), write a few sectors worth of zeros
at the beginning of your device first.

> Is parted zero-based, one-based, or an indeterminate mixture of the two? If I
> use units of Bytes and say to start the partition at byte 1048576, parted
> insists that it cannot start there, that it must start 512 bytes earlier.

Again, please show precisely what command(s) you ran
and the output parted printed.

> And where do partitions really start and end? If I use units of MiB, then I
> can start a partition at 1MiB and end it at 200MiB. But parted insists that
> the partition is 199MiB. So it seems the specified end is really the block
> *after* the last block of the parttion. But only for MiB.

Please show the commands you ran and then the output of this command
for your device:

    parted -s /dev/XXX u s p u gi p

Do you mean that the length is 199MiB?
Wouldn't you expect that if it starts at 1MiB and goes to 200MiB?

> I've gone to the trouble of computing partition sizes to exact byte
> boundaries. And even *that* doesn't work. It is infuriating to have parted
> tell me that it cannot start a partition at byte 1048576, even though that
> byte is the first byte of the second 1MiB 'section'--it is well-aligned, and
> that the nearest it can find is byte 1048064, which is *clearly* not aligned
> to anything but 512-byte sectors.
>
> The documentation is horribly incomplete. How many years has parted existed?
> And trial&error is *still* the only way to find out what works and what
> doesn't?
>
> Parted is now at version 3.0; now is a fine time to fix the long-standing
> problems. Please go through the code with a nanometer-spaced comb and fix it.
>   - Please choose one absolute byte where partitions can begin. Make it
>     consistent throughout the entire program. Publish this number.

Not possible.
The numbers differ depending on which partition table type you use.

>   - Please choose and publish an alignment scheme. I don't care if you choose
>     512-byte sectors, 4KiB sectors, 1MiB sectors, or even 1GiB sectors for
>     partition alignment. Pick one and be consistent throughout the program.
>   - Please make 'start' must be the first block or byte of the partition; fix
>     the computations to perform error checking correctly regardless of the
>     selected units.
>   - Please make 'end' must be the last block or byte of a partition.
>     Again, fix the computations to perform error checking correctly.
>   - Please clearly state the last usable block or byte of the drive, or how to
>     compute it; please don't force any more people to restort to trial and
>     error to find out where they can end their disk usage.

Examples address this: use -1B for the last byte
or -1s for the last sector.  With GPT, you'll want to use -34s.

>   - Please clearly state *where* on the disk GPT stuff is stored. I have
>     zeroed the first 100MB and last 100MB of a drive, only to have sfdisk
>     whine about finding a GPT table.

That is standard:

  https://secure.wikimedia.org/wikipedia/en/wiki/GPT_Disk

The primary GPT table usually occupies sectors 1..33
with the 0th (first) sector being the so-called protective MBR.
and the backup one is in the last 33 sectors of the device.