Red Hat Bugzilla – Bug 865821
When custom partitioning, reclaimed partitions are in two lists rather than one
Last modified: 2014-02-05 07:33:54 EST
I have a F17 x86_64 system where I am installing F18. It uses LVM -- one hard disk with one PV and one VG, separated into several LVs. One of the LVs is /home, thus I want to do custom partitioning to retain this data. Since previous Fedora installs use LVM, I suspect this case is not uncommon.
When I go to the custom partitioning screen, my previous F17 x86_64 installation is detected and the LVs appear as expected. When I "reclaimed" a partition by giving it a mount point, it remained in both the F17 x86_64 list and the new F18 list when I hit "Apply changes."
Because the UI only allows me to see one expanded list at a time, it's not apparent what's happening. I suggest that the partition should be removed from the F17 x86_64 list and inserted in the F18 list to make the operation more apparent. It might also be appropriate to offer some feedback to the user since the partition will otherwise seem to disappear, which may be confusing.
I've also experienced this using F18 Beta TC3 32 bits DVD ISO image.
In my case, I had previously installed F18 Beta using this same image and was just trying to overwrite the installation. Storage told me that I had not free space, so I said that "I didn't need help" and pressed "Reclaim space" button.
After that, the previous F18 beta installation was recognized, and added under a "Fedora 18" entry. So I was being presented with 2 Fedora 18 entries: a new one, and the old one.
[Another UI problem, in my opinion]
In the "New" installation, I'm indicated that I should press the "+" button to create a new "mount point", not a new partition but a _mount point_, which is, in my opinion, misleading, because pressing the "+" button tries to create a new partition and the mount point.
[Problem reported in bug]
Then I realized that I could set the mount point for the old installation partitions under the second recognized F18, but as original reported indicated, partitions were kept under both installations, so I was not sure what I was doing.
Also, I was never informed if the partitions were going to be formatted or not! So I wasn't sure if trying to reuse an old /home partition would format all its contents or just be used like that without formatting. By the way, I'm not sure if it was formatted or not at all because this Anaconda installation hanged and previous correct F18 installation partitions were corrupted.
While I'm sure everyone would be happier with a whole bunch of pop-up dialogs making things abundantly clear, let me explain the logic here instead:
If you set a mountpoint on an existing filesystem without reformatting it, you aren't really invalidating its role in other installations. Therefore, we do not remove the filesystem from those other installations in the UI.
If, OTOH, you set a mountpoint and also reformat a device containing an existing filesystem, you are almost certainly invalidating whatever role it played in any other installation. In this case we remove the filesystem from the old installations in the UI.
Similarly, if you hit the minus button on an existing device while viewing the new fedora installation, all changes to that devices are reverted and the device is returned to any installations it was previously a part of.
If you hit the minus button on a device/filesystem in any of the other installations you are asking to actually remove the device from your disk(s).
While all of the above makes sense to me and others on the installer team, I realize that it may not be completely intuitive. I'm not sure what can be done to smooth out the experience for new users.
@dlehman -- Great explanation, thanks. I hadn't considered the case of shared partitions; now it actually makes more sense. Currently I don't have that particular Anaconda page in front of me. Is there any space where this could be explained to the user without mucking up the interface?
E.g.: 'Disk partitions appear in the listing of each system that can access them. Partitions whose system usage cannot be detected automatically are listed under "Unknown".'
...Or some such. I agree, a bunch of popups shouldn't be required.
@jacobo: If you have a different issue, please file it as a separate bug. Mixing up issues in one bug makes things harder on the developers. This bug is only about how partitions are listed in the system breakouts.
(In reply to comment #3)
> @dlehman -- Great explanation, thanks. I hadn't considered the case of
> shared partitions; now it actually makes more sense. Currently I don't have
> that particular Anaconda page in front of me. Is there any space where this
> could be explained to the user without mucking up the interface?
I am hoping to find time to write a short primer on how the new interface works and have it displayed initially upon entering the custom storage configuration "spoke" for the first time. We might want to make it available through a "help" button of some sort. The text you provided is of a similar tone to what I had imagined for the primer.
Here is an off-the-cuff outline:
- brief explanation of the screen layout
- user, meet top-down device specification
- create your filesystems and then you can tweak them
- there is no need to manually create building-block
devices -- we'll handle the details for you
- how to create a new filesystem
- how to remove an existing filesystem
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
Thank you for reporting this bug and we are sorry it could not be fixed.