units shown are not equal to the units asked for creation

[ceg]

Try to recreate or clone the OS partition on another harddrive of a different size as the original.

GParted shows only an impresize size of the existing partition such as "32.63GB", whereas to create the new partition the exact size in MiB is required.

Hidden in the Properties, gparted does tell the number of sectors in the old partition, but that can't be directly used to create the new partition either. (V 0.7.0)

Use case is not to copy but create two disks with same partiton sizes (only some of them raid partition clones).

--

Suggested fix:

* Also show the (full length) size in MiB in the detailed properties window, since this is the standard allign unit anyway.

[Curtis Gedak (gedakc)]

GParted displays partition sizes using units that try to keep the digits before the decimal place to three or less.

When the Move/Resize or the Copy dialog box is first shown, the current size is shown in mebibytes in the "New size (MiB)" field.

[ceg (ceg)]

Thanks for the workaround! Having to look into Move/Resize before creating new partitions is still strange, though.
I would expect the required unit numbers are available, at least in the detailed properties of partitions.

[ceg (ceg)]

Use case was, not to copy but create two disks with same partiton sizes (only some of them raid partition clones).

[Curtis Gedak (gedakc)]

When GParted creates partitions, it uses the size in MiB as a guideline. The size on disk can vary depending upon the setting of the "Align to" drop down box.

See Specifying Partition Alignment
http://gparted.org/display-doc.php?name=help-manual#gparted-specify-partition-alignment

[ceg (ceg)]

When I had the problem I finally had to turn to CLI-parted to get the proper numbers. Nothing a graphical tool user may like to do, but I could work around the problem that way.

Fortunately, I was using the MiB allignment on all newer disks, so they should have ended up to have the same size as I defined exact MiB, too.

It just feels really wrong if the graphical partitioning tool you are using asks for information in a unit that it can not supply (without going into unrelated modes). It would have been no problem if the info is in the detailed properties. Thus if you could add it there, that would be great.

[Phillip Susi (psusi)]

I thought there was already a bug about allowing size entry in units other than MiB, but I can't seem to find it now. Allowing entry in sectors sounds like it would fix this.

[ceg (ceg)]

Can't sectors per MiB be different on different harddisks?
But the LBA size "sectors?" may be the right option for below MiB alligning.

[Curtis Gedak (gedakc)]

> Can't sectors per MiB be different on different harddisks?
> But the LBA size "sectors?" may be the right option for below MiB alligning.

Sector size can vary from the traditional 512 bytes per sector. Hence sectors per MiB can be different on different hard disks. I believe the same can be said for LBA size "sectors".

There are already a few other upstream bug reports that involve allowing different units:

612928 - File size units not consistent with GNOME desktop
https://bugzilla.gnome.org/show_bug.cgi?id=612928

622150 - Support for data entry and display of logical blocks (sectors)
https://bugzilla.gnome.org/show_bug.cgi?id=622150

With this in mind, perhaps this bug report should deal only with adding the size in MiB to the "Partition --> Information" dialog?

[ceg (ceg)]

Agreed. Thank you!

[ceg (ceg)]

The workarout to see the MiB size in copy/resize dialog does not work with "unknown" partitions (raids containing luks).

[ceg (ceg)]

console workaround to get the size in MiB:

# parted /dev/sda unit MiB print