Bug 890711

Those seem correct to me, if 1 MB == 1000**2 bytes and 1 GB == 1000**3 bytes. The problem here, IMO, is that the installer does not make it clear exactly what those units mean, even though they are standardized:

Mebibyte
http://en.wikipedia.org/wiki/Mebibyte

Even better would be for the installer to offer users an option to select the units, much as parted does.

That doesn't make any sense.  The article you cited says that 1 MB == 1024**2 bytes and 1 GB == 1024**3 bytes (technically 2^20 and 2^30 respectively).

Besides, when I boot into the machine, df returns the 6.5 GB, 1.0 GB, and 8.0 GB I was expecting -- not the off numbers anaconda cited.  If anaconda was right, then df would be wrong.  Or if df wasn't wrong, it would mean that anaconda created partitions of incorrect size.  That's even worse than just doing an incorrect unit conversion.

Thanks for pointing that out. The Wikipedia table is confusing ...

This is what the units mean:[1]

1 MB:  1000**2 bytes
1 GB:  1000**3 bytes

1 MiB: 1024**2 bytes
1 GiB: 1024**3 bytes

NB: The installer accepts size units with a binary prefix: "1 MiB", "1 GiB".

[1] International Electrotechnical Commission
Quantities and units / Basic concepts	
binary prefix
http://www.electropedia.org/iev/iev.nsf/display?openform&ievref=112-01-27

Created attachment 670248 [details]
[18.37.8] screenshot showing Manual Partitioning dialog

I confirm that the installer is using size units incorrectly and inconsistently.

Name        Entered     Displayed   Created (per parted)
/           4000 MB     4 GB        4000 MiB
/p_500_MB   500 MB      500 MB      500 MiB
/p_500_MiB  500 MiB     524 MB      524 MiB
/p_1_GB     1 GB        1 GB        1000 MiB
/p_1_GiB    1 GiB       1.07 GB     1073 MiB
/p_1000_MB  1000 MB     1 GB        1000 MiB
/p_1000_MiB 1000 MiB    1.04 GB     1048 MiB

NB: These are listed in the order I entered them. The installer reorders them.

Test procedure:

Create an empty 12 GiB disk image:
$ qemu-img create f18-test-3.img 12G

Start the Live CD and and update anaconda:
$ qemu-kvm -m 2048 -hda f18-test-3.img -cdrom ~/xfr/fedora/F18/F18-Final/TC3/Fedora-18-TC3-x86_64-Live-Desktop.iso -usb -vga qxl -boot menu=on -usbdevice mouse

anaconda-18.37.8-1.fc18

For simplicity, from Installation Options select Partition type: Standard Partition.

Here is the parted report used to fill the "Created" column in Comment 4.

[root@localhost liveuser]# parted /dev/sda unit MiB print
Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 12288MiB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start    End       Size     Type      File system  Flags
 1      1.00MiB  4001MiB   4000MiB  primary   ext4         boot
 2      4001MiB  5074MiB   1073MiB  primary   ext4
 3      5074MiB  6074MiB   1000MiB  primary   ext4
 4      6074MiB  12288MiB  6214MiB  extended
 5      6075MiB  7075MiB   1000MiB  logical   ext4
 6      7076MiB  7600MiB   524MiB   logical   ext4
 7      7601MiB  8101MiB   500MiB   logical   ext4
 8      8102MiB  9150MiB   1048MiB  logical   ext4

[root@localhost liveuser]# lsblk /dev/sda
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   12G  0 disk 
├─sda1   8:1    0  3.9G  0 part /mnt/sysimage
├─sda2   8:2    0    1G  0 part /mnt/sysimage/p_1_GiB
├─sda3   8:3    0 1000M  0 part /mnt/sysimage/p_1000_MB
├─sda4   8:4    0    1K  0 part 
├─sda5   8:5    0 1000M  0 part /mnt/sysimage/p_1_GB
├─sda6   8:6    0  524M  0 part /mnt/sysimage/p_500_MiB
├─sda7   8:7    0  500M  0 part /mnt/sysimage/p_500_MB
└─sda8   8:8    0    1G  0 part /mnt/sysimage/p_1000_MiB
[root@localhost liveuser]#

Created attachment 670463 [details]
[18.37.8] anaconda.log

Created attachment 670464 [details]
[18.37.8] anaconda.program.log

Created attachment 670465 [details]
[18.37.8] anaconda.storage.log

Anaconda uses 1GB == 1000MB, as is common when describing storage and consistent with the usage in parted. comment 5 does not show any inconsistency: the partitions created with MB as the unit were created in units of 10**6 bytes, which partitions created with MiB as the unit were create in units of 2**20 bytes, which is exactly what those units mean in this context.

The installer allows size units to be given in "MB" or "MiB".

Comment 4 reports the numerical size and the units that were entered in the installer in the column labeled "Entered". The actual size of the resulting partition does not match what was entered. Taking the example highlighted in the screenshot, which applies to sda8:

Size entered: 1000 MiB
Size created: 1048 MiB

Those are not the same.

You need to complete the install and see what is actually created on disk using parted with units set to MiB.

The parted "unit" command is documented in the parted man page:
$ man parted

unit unit
       Set unit as the unit to use when displaying locations and
       sizes, and for interpreting those given by the user  when
       not  suffixed  with an explicit unit.  unit can be one of
       "s" (sectors), "B"  (bytes),  "kB",  "MB",  "MiB",  "GB",
       "GiB",  "TB",  "TiB",  "%"  (percentage  of device size),
       "cyl" (cylinders), "chs" (cylinders, heads, sectors),  or
       "compact" (megabytes for input, and a human-friendly form
       for output).

Hang on.  EVERY other disk utility including ls, df, du, and parted uses MiB (1024**2) by default, instead of MB (1000**2).  At the very least, isn't this inconsistent in terms of user interface?  Shouldn't the default match other utilities?

I would think this would be detracting for those who aren't power users.

And how do change over to MiB (1024**2) units?  This isn't clear to me.

In the input for the partition size, you can enter, for example, '500 MiB' instead of '500 MB'

Created attachment 788993 [details]
[19.30.13] screenshot showing a size of "1 gib" being specified in the Add a New Mount Point dialog

Thanks for your comments, Joseph.

In the Add a New Mount Point dialog, for example, you can specify size units for the Desired Capacity. See attached screenshot.

AFAICT, the Manual Partitioning Help page does not say that you can specify size units. The tooltip gives some help, but it does not list all possible allowed units.

NB: The installer does not guarantee to allocate the exact size you specify. The Manual Partitioning Help page alludes to this in the "Tips and hints" section.

Created attachment 788998 [details]
[19.30.13] terminal session showing partition sizes that do not match what was specified in the installer

This is still a bug in F19. Partitions with sizes specified in the installer in units of MiB or GiB are not created with those sizes.

The attached terminal session shows the details. The file system labels in the lsblk output show the sizes specified in the installer. The parted output in both MiB and GiB shows that none of the partitions have the specified sizes. In particular:

sda3 was specifed to have a size of "1 gib", but the parted report shows that it is 1.05GiB.

sda5 was specified to have a size of "1000 mib", but the parted report shows that it is 1048MiB.

Tested with:
$ qemu-kvm -m 4096 -hda f19-test-3.img -cdrom ~/xfr/fedora/F19/Fedora-19-x86_64-DVD.iso -vga std -boot menu=on

Created attachment 788999 [details]
[19.30.13] parted output showing partition sizes in bytes: parted /dev/sda u B p free

(In reply to Steve Tyler from comment #15)
> Created attachment 788999 [details]
> parted output showing partition sizes in bytes: parted /dev/sda u B p free

Python agrees with the parted unit conversions:

>>> print 'sda3:', 1125122048.0/1024**3, 'GiB'
sda3: 1.0478515625 GiB

>>> print 'sda5:', 1098907648.0/1024**2, 'MiB'
sda5: 1048.0 MiB

Joseph: If you can confirm these results[1] with F19, there will be more than enough evidence to reopen this bug against F19.

[1] Comment 14, Comment 15, Comment 16.

Created attachment 789021 [details]
[19.30.13] anaconda.log

Created attachment 789022 [details]
[19.30.13] anaconda.program.log

Created attachment 789023 [details]
[19.30.13] anaconda.storage.log

Created attachment 789025 [details]
[19.30.13] anaconda-ks.cfg

Aside from possible truncation error, the sizes in the kickstart file[1] appear to be correct[2], if they are assumed to be in units of MB (1000**2 bytes).

/boot       --size=524  --label=p_500_mib
>>> 500.0*1024**2/1000**2
524.288

/p_1000_mib --size=1048 --label=p_1000_mib
>>> 1000.0*1024**2/1000**2
1048.576

/           --size=8589 --label=p_8_gib
>>> 8.0*1024**3/1000**2
8589.934592

/p_1_gib    --size=1073 --label=p_1_gib
>>> 1.0*1024**3/1000**2
1073.741824

[1] Redundant and irrelevant entries from the kickstart "part" options have been removed:

# Disk partitioning information
part /boot --fstype="ext4" --maxsize=524 --ondisk=sda --size=524 --label=p_500_mib
part /p_1000_mib --fstype="ext4" --maxsize=1048 --ondisk=sda --size=1048 --label=p_1000_mib
part / --fstype="ext4" --maxsize=8589 --ondisk=sda --size=8589 --label=p_8_gib
part /p_1_gib --fstype="ext4" --maxsize=1073 --ondisk=sda --size=1073 --label=p_1_gib

[2] The arithmetic converts MiB and GiB to MB.  Arithmetic by Python.

The bug here is that the kickstart file is specifying sizes in units of MB, but the partitions are created as though those sizes are in units of MiB.

sda1 (p_500_mib)
kickstart:  --size=524
parted:     524MiB

sda2 (p_8_gib)
kickstart:  --size=8589
parted:     8589MiB

sda3 (p_1_gib)
kickstart:  --size=1073
parted:     1073MiB

sda5 (p_1000_mib)
kickstart:  --size=1048
parted:     1048MiB

Created attachment 789032 [details]
Joe's Screenshots

(In reply to Joseph D. Wagner from comment #24)
> Created attachment 789032 [details]
> Joe's Screenshots

Thanks, Joe. Very nice work. I typed in this table from your screenshots:

Device          Specified   Displayed   Parted(MiB) Parted(MB)
vda1 (/boot)    512 MiB     536 MB      536MiB      562MB
vda2 (swap)     1 GiB       1.073 GB    1073MiB     1125MB
vda3 (/)        ?           2.486 GB    2486MiB     2607MB

Do you recall how you specified the size of vda3?

vda3 was simply all remaining space on a 4096 MiB drive.  anaconda picked the amount automatically.

OK, thanks. Your results[1] confirm mine[2] -- the installer is creating partitions in units of MiB instead of MB.

This bug can be reopened against F19, IMO.

[1] Comment 24, Comment 25.
[2] Comment 22, Comment 23.

(In reply to Steve Tyler from comment #27)
...
> This bug can be reopened against F19, IMO.
...

I believe the relevant component is python-blivet:

$ grep -Rl newPartition blivet-0.17-1/
blivet-0.17-1/blivet/partitioning.py
blivet-0.17-1/blivet/devicefactory.py
blivet-0.17-1/blivet/__init__.py

$ sudo repoquery python-blivet --repoid=fedora
python-blivet-0:0.17-1.fc19.noarch

https://git.fedorahosted.org/git/blivet.git
https://bugzilla.redhat.com/buglist.cgi?component=python-blivet&list_id=1641069

Instead of changing the backend to match the UI, can we change the UI to match the backend?  I think a lot of people expect MiB/GiB and would prefer it, especially since it would match other utilities like ls, df, and du.

You really have two bugs here:
1. What units the GUI should display sizes in -- or units, if the display units can be user-specified. (Comment 1, last sentence)
2. The partition sizes do not match the specified sizes. This is a definite bug.

IME, the anaconda developers do not like GUI design changes, so getting #1 changed is going be an uphill battle.

They also don't like multiple bugs in one.

I can open a new bug for #2, if you want to fight the GUI design change in this one.

What do you want to do?

Let's focus on the real bug, and I'll try to make my case for a UI design flaw separately.

(In reply to Joseph D. Wagner from comment #31)
> Let's focus on the real bug, and I'll try to make my case for a UI design
> flaw separately.

OK, thanks. I can't reopen this bug or change the release to F19, but you can.

I would suggest restating the bug summary, so that it is clear that this bug is addressing the problem of partitions being created with incorrect sizes, say:

"partition sizes do not match specified sizes"

I believe the component should be python-blivet, but haven't been able to drill down into the code far enough to find where it actually creates partitions.

You can download source tarballs from here, if you want to take a look:
https://git.fedorahosted.org/cgit/blivet.git/

Other relevant components are pyparted and anaconda. Source is here:
https://git.fedorahosted.org/cgit/pyparted.git
https://git.fedorahosted.org/git/anaconda.git

F19 versions are:

$ sudo repoquery python-blivet pyparted anaconda --repoid=fedora --releasever=19
anaconda-0:19.30.13-1.fc19.x86_64
pyparted-1:3.9-3.fc19.x86_64
python-blivet-0:0.17-1.fc19.noarch

There is a fair amount of inconsistency in python-blivet with regard to size units. I have a patch in development that will straighten this out. The matter of which unit anaconda will show/use by default is separate.