Description of problem: anaconda installer does not find/show unallocated space in extended partitions but only that outside of it. Unallocated space in extended partitions must be formatted before in order to be used. Version-Release number of selected component (if applicable): anaconda-21.48.13-1.fc21 How reproducible: - Running Anaconda from a Fedora Workstation live beta - Try to create Fedora standard partitions on an pre-existing extended partition that contains unallocated space.
Please attach the log files from /tmp to this bug as individual, text/plain attachments.
(In reply to David Shea from comment #1) > Please attach the log files from /tmp to this bug as individual, text/plain > attachments. There is not any log file in /tmp # ls /tmp dnf-O6KT2Z systemd-private-848301599f1b453eabcbabc58af3e289-colord.service-GmScyz systemd-private-848301599f1b453eabcbabc58af3e289-rtkit-daemon.service-M7Ca8k hogsuspend systemd-private-848301599f1b453eabcbabc58af3e289-cups.service-WUwPgL tracker-extract-files.100 # ls -R /tmp | grep log
Start the installer. After it has done the disk allocation, switch to the console with CTRL-ALT-F2. You will find several log files in /tmp. Transfer them off with ftp, scp, usb drive, or whatever way you can.
Created attachment 957260 [details] anaconda's log from fedora-21 live Currently, there is just a tiny unallocated partition (2MB) on my disk. I hope it's sufficient to examine this issue.
The output of 'parted /dev/sda print' might be useful, but from what I can tell in the logs you have no free space in your extended partition. Here are the sizes of the relevant devices (taken from storage.log): >>> sda = Size("465.76 GiB") >>> sda4 = Size("272.55 GiB") >>> sda5 = Size("500 MiB") >>> sda6 = Size("136.03 GiB") >>> sda7 = Size("136.03 GiB") >>> sda4 - (sda5 + sda6 + sda7) Size('1802.24 KiB') That 1802.24 KiB free is not usable because partitions must be aligned on MiB boundaries, which means the minimum size for a new partition is 1MiB.
Sorry, that last sentence was not very clear or accurate. Due to partition alignment, which requires partitions to start and end on MiB boundaries, the 1802 KiB of unallocated space in your extended partition is unusable. Is the fact that we do not mention this space the problem being reported?
(In reply to David Lehman from comment #6) > Sorry, that last sentence was not very clear or accurate. > > Due to partition alignment, which requires partitions to start and end on > MiB boundaries, the 1802 KiB of unallocated space in your extended partition > is unusable. > > Is the fact that we do not mention this space the problem being reported? That tiny unallocated space at start of extended partition was already present before to use Anaconda from Fedora 21 beta (i have not informed you of that, sorry); it is very small so I prefered to leave it unallocated instead of add it to adjacent formatted partition. Before to use Anaconda there was also another unallocated space in same extended partition (now it does not exist anymore). Did tiny unallocated space prevented to detect all unallocated space in the extended partition? When you say "Due to partition alignment, which requires partitions to start and end on MiB boundaries, the 1802 KiB of unallocated space in your extended partition is unusable", do you mean that partitions must be sectioned in integer of MiB? (1MiB or 12MiB and not 12.5MiB)
(In reply to Antonio Trande from comment #7) > Did tiny unallocated space prevented to detect all unallocated space in the > extended partition? No. I don't understand exactly what behavior you are talking about. You have not provided a screen shot or any specific description of why you believe anaconda was unable to detect free space in your extended partition. There is no real information to work with. > When you say "Due to partition alignment, which requires partitions to start > and end on MiB boundaries, the 1802 KiB of unallocated space in your > extended partition is unusable", do you mean that partitions must be > sectioned in integer of MiB? (1MiB or 12MiB and not 12.5MiB) That is correct. It is not strictly required, but it is strongly recommended for optimal I/O performance. For this reason, anaconda aligns all partitions it creates.
(In reply to David Lehman from comment #8) > (In reply to Antonio Trande from comment #7) > > Did tiny unallocated space prevented to detect all unallocated space in the > > extended partition? > > No. I don't understand exactly what behavior you are talking about. I meant if two or more unallocated spaces of same extended partition can influence each other in some way. > You have not provided a screen shot or any specific description of why you believe anaconda was unable to detect free space in your extended partition. > There is no real information to work with. Sorry, I wanted to install Fedora 21 as soon as possible so I recovered that unallocated space without examine in depht the problem. > > > When you say "Due to partition alignment, which requires partitions to start > > and end on MiB boundaries, the 1802 KiB of unallocated space in your > > extended partition is unusable", do you mean that partitions must be > > sectioned in integer of MiB? (1MiB or 12MiB and not 12.5MiB) > > That is correct. It is not strictly required, but it is strongly recommended > for optimal I/O performance. For this reason, anaconda aligns all partitions > it creates. I think this was the real trouble.
(In reply to Antonio Trande from comment #9) > (In reply to David Lehman from comment #8) > > (In reply to Antonio Trande from comment #7) > > > Did tiny unallocated space prevented to detect all unallocated space in the > > > extended partition? > > > > No. I don't understand exactly what behavior you are talking about. > > I meant if two or more unallocated spaces of same extended partition can > influence each other in some way. They cannot. > > > You have not provided a screen shot or any specific description of why you believe anaconda was unable to detect free space in your extended partition. > > There is no real information to work with. > > Sorry, I wanted to install Fedora 21 as soon as possible so I recovered that > unallocated space without examine in depht the problem. > > > > > > When you say "Due to partition alignment, which requires partitions to start > > > and end on MiB boundaries, the 1802 KiB of unallocated space in your > > > extended partition is unusable", do you mean that partitions must be > > > sectioned in integer of MiB? (1MiB or 12MiB and not 12.5MiB) > > > > That is correct. It is not strictly required, but it is strongly recommended > > for optimal I/O performance. For this reason, anaconda aligns all partitions > > it creates. > > I think this was the real trouble. I don't see how it could be unless you were trying to create partitions of less than 1MiB in size.
(In reply to David Lehman from comment #10) > > > > > > > When you say "Due to partition alignment, which requires partitions to start > > > > and end on MiB boundaries, the 1802 KiB of unallocated space in your > > > > extended partition is unusable", do you mean that partitions must be > > > > sectioned in integer of MiB? (1MiB or 12MiB and not 12.5MiB) > > > > > > That is correct. It is not strictly required, but it is strongly recommended > > > for optimal I/O performance. For this reason, anaconda aligns all partitions > > > it creates. > > > > I think this was the real trouble. > > I don't see how it could be unless you were trying to create partitions of > less than 1MiB in size. I had tried to use unallocated space in an extended partition but I think it has been sectioned bad, meaning that it occupied a space of MiB not integer. For instance, an unallocated space of 51,83 GiB maybe could not be detected by Anaconda, like so happens with a tiny unallocated space of 1802 KiB.
No, it doesn't work like that. It will just adjust the start and end positions to be at MiB boundaries, so it could leave tiny gaps. But that shouldn't stop it from finding the space and creating the partitions.
Given that we're all just guessing at this point, and that the situation hit by the reporter no longer exists, I think we can close this bug.