Description of problem: During custom partitioning, user-input sizes which specify a unit of MiB ((1<<20) bytes) or GiB ((1<<30) bytes) are accepted but are not inteprreted correctly. Version-Release number of selected component (if applicable): anaconda-18.23 How reproducible: every time Steps to Reproduce: 1. Boot install DVD in UEFI mode with harddrive that has GPT but no partitions. 2. Custom partition 50MiB for /boot/efi, 500MiB for /boot, 15GiB for / (root), 4GiB for swap. 3. switch to shell on VT2; print layout using "parted /dev/sda" Actual results: Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: parted> unit MiB parted> print Number Start End Size File system Name Flags 1 1.00MiB 53.0MiB 52.0MiB fat16 EFI System Partition boot 2 53.0MiB 577MiB 524MiB ext4 3 577MiB 16683MiB 16106MiB ext4 4 16683MiB 20977MiB 4294MiB linux-swap(v1) Expected results: Number Start End Size File system Name Flags 1 1.00MiB 51.0MiB 50.0MiB fat16 EFI System Partition boot 2 51.0MiB 551MiB 500MiB ext4 3 551MiB 15911MiB 15360MiB ext4 4 15911MiB 20007MiB 4096MiB linux-swap(v1) Additional info: The output from parted accurately reports reality. The raw partition table has (od -Ax -tx4 /dev/sda): 000400 c12a7328 11d2f81f a0004bba 3bc93ec9 000420 00000800 00000000 0001a7ff 00000000 # 0x800*512 = 1.00MiB; (1+0x1a7ff)*512 = 0x3500000 = 53MiB 000480 ebd0a0a2 4433b9e5 b668c087 c79926b7 0004a0 0001a800 00000000 001207ff 00000000 000500 ebd0a0a2 4433b9e5 b668c087 c79926b7 000520 00120800 00000000 020957ff 00000000 000580 0657fd6d 43c4a4ab 3309e584 4f4f4bc8 0005a0 02095800 00000000 028f87ff 00000000
Partition sizes provided by the user are really best-effort numbers for anaconda. Plus, keep in mind we apply whatever alignment values the kernel provides us, which means partitions can be slightly different sizes than what you expect. Can you also attach /tmp/storage.log?
Created attachment 638750 [details] /tmp/storage.log The kernel says align to 1MiB. All user-specified sizes were in MiB or GiB, so they are aligned already.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.