Created attachment 670011 [details] Screenshot of unit conversion error Description of problem: When manually partitioning in F18 Beta, anaconda incorrectly converts between MB and GB by using 1000. This results in an incorrect reporting of available space, free space, and partition sizes in the left-sidebar. Instead, it should use 1024. Version-Release number of selected component (if applicable): Whichever version is on the F18 Beta DVD. How reproducible: Always Steps to Reproduce: 1. Enter units in MB. 2. GB conversions on left are incorrect. Actual results: A 6656 MB partition was displayed as 6.65 GB. A 1024 MB swap was displayed as 1.02 GB. Total space was displayed as 8.19 GB. Expected results: The 6656 MB partition should have been displayed as 6.5 GB. The 1024 MB swap should have been displayed as 1.00 GB. The Total space should have been displayed 8.00 GB. Additional info: See screenshot.
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.