Just a quick top-post note: I don't mean for this summary to dictate a
solution to the developers or indicate a specific timeline, this is just
a UX-centric recommendation. It's up to the development team what to do
with the recommendation (if anything) and when.
~m
On 10/13/2015 04:46 PM, Máirín Duffy wrote:
Hi,
A couple of weeks ago this bug / issue was brought to my attention since
it effects the user experience:
https://bugzilla.redhat.com/show_bug.cgi?id=1183880
We had a lot of discussion about it in #anaconda, especially regarding
what the user experience should be here, so I wanted to provide a
run-down of what was discussed and what we'd decided to do moving forward.
======
TL;DR Summary:
- After a lot of discussion I think proposed solution #3 is the way to
go and there is a pull request with a patch that does it (plus a video
screencast!): https://github.com/rhinstaller/anaconda/pull/383
======
Symptoms of Issues:
===================
adamw helpfully made a screencast of the issue, which I'll describe here
as well in case the video stops working at some future point:
https://www.youtube.com/watch?v=PcUd4K0iM6c
- You have a dual-boot system with Windows and Fedora installed
side-by-side, using UEFI. (/boot/efi used by both Windows and Fedora)
- Load up anaconda (presumably to remove / reinstall Fedora) and go to
the custom partitioning UI.
- The /boot/efi partition only shows up under the Fedora header. It's
not shown under the 'Unknown' header that represents the Windows
installation.
- It's not clear from the UI then, that the /boot/efi partition is used
by more than one OS nor is it clear it's necessary for the Windows stuff.
- If you want to remove Fedora, you start by clicking on one of the
Fedora partitions and hit the '-' button to delete it. The dialog that
pops up has a helpful affordance that offers to delete all Fedora
partitions in one go for you (delete-all-parts.png, attached).
- Problem is if you use the affordance of deleting all partitions at
once (or just delete them all, one-by-one, not realizing /boot/efi is
shared), you'll end up with a new Fedora install and an unbootable
Windows install.
Assumptions / Caveats:
======================
- Dual boot support is something we provide a minimal level of support
for. "The installer must be able to install into free space alongside an
existing clean Windows installation and install a bootloader which can
boot into both Windows and Fedora." (from Fedora final release criteria)
- The issue does not happen with the reclaim space or automatic
partitioning paths, which are the recommended paths for this use case.
Custom partitioning is a third case here and the case where we expect
the most of the user and their knowledge (altho is the required path for
non-default FS / container type.) Custom part is not about education of
users, it's about giving users access to controls beyond the recommended
defaults we supply.
- What about disks that haven't been selected? e.g., could a windows
install that uses an ESP on the selected disks be on a disk that is
unselected, so we can't detect that the ESP could be potentially used by
another OS? (Could always put ESP under unknown.... this would be safe.)
It's also - if at all possible - going to be extremely rare that Windows
would be on the different disk than the ESP so this case is minimal
enough not to be much of a nuisance hopefully.
- Windows multibooters do the Windows install first, and Fedora second.
Summary of Issues / Angles of Approach
=======================================
1) ESPs are special.
EFI system partitions (ESPs) are kind of 'special' (isn't everything in
storage?!) in that they aren't really related to the OS, so if you're
trying to delete an OS you don't necessarily want to delete the ESP.
Anaconda intentionally reuses any existing ESPs when installing Fedora
which results in shared ESPs for multi-boot systems. (It is possible to
manually create a new ESP by not clicking on the 'create them for me'
link in the UI, though, and everything will boot okay - adamw tested this.)
** We ended up persuing potential solutions that focused on this angle
of the problem as we have control over how we handle ESPs.
2) We are limited in our ability to represent non-Linux OSes.
We don't have a way to detect Windows installations and identify them as
such and assemble them in the partition viewer the way we can with
Fedora. The Windows partitions show up under an "Unknown" bucket and we
don't have a way of knowing the ESP is related so we don't put it in the
same bucket. (This is not the case for OSes we know about.)
Not a great angle to approach the problem from because we don't have
control over what non-Fedora OSes do.
3) No multi-select capability in partition widget.
While the checkbox affordance to delete all partitions in an OS is
*very* nice, some multi-select capability in the widget to let someone
shift-click multiple partitions at once would provide more flexibility
and would at least allow for folks who knew not to delete the ESP to
avoid it in their selection. (This would also help with managing thinp
or btrfs where you might have many, many partitions)
Pre-existing bug: https://bugzilla.redhat.com/show_bug.cgi?id=1265620
Proposed Solutions:
===================
(These were discussed both in the github pull request #377
https://github.com/rhinstaller/anaconda/pull/377 and in #anaconda on
October 1)
1) New Bucket for ESPs
----------------------
PR: https://github.com/rhinstaller/anaconda/pull/377
Put all EFI system partitions into a separate 'bucket' in the partition
list.
This is jkonecny's PR. He created a separate "UEFI partitions" bucket
that the UEFI partitions would go in. The ESP wouldn't show up in the
existing system.
downside: the same ESP shows up in the UEFI partitions bucket multiple
times, one time for each OS root we know it's associated with. it's a
bit jarring to have multiple entries for the same thing.
downside: in the F23 timeline this was a lot of change late and there
was worry it might introduce other unforeseen issues.
SUMMARY:
We were worried the multiple entries per ESP would be too problematic
and thought #3 might be a more polished solution with a minimal amount
of change.
2) Hide all firmware-boot related partitions
--------------------------------------------
Treat all firmware-boot related partitions as being details of the boot
process and hide them from the user.
"except then people would want an even more custom partitioning, that
allowed them to do things to everything" (clumens)
"i think there's a reasonable argument that by 'custom partitioning'
what's really expected is 'custom layout of OS bits'" (adamw)
SUMMARY:
With our userbase, the loss of flexibility / control was going to be
problematic and would escalate the issue in terms of UX. It's also a
major code / functionality change. So this change is pretty big /
complex and would have a lot of other effects we'd need a lot of
planning around.
3) Silently fail to delete ESPs when user checks off 'delete all'
-----------------------------------------------------------------
PR:
https://github.com/rhinstaller/anaconda/pull/383
Patch Demos (via adamw shakycam):
- Windows/Fedora: https://www.youtube.com/watch?v=e4PIOf8K538
- Fedora/Fedora: https://www.youtube.com/watch?v=PgpOXgI1f-c
When 'delete all' is clicked, don't delete shared devices, and don't
delete bootloader partitions if there are unknown partitions (for
Windows multiboot case) or if the device is shown in more than one root
(for Linux multiboot case.) If there are no unknown partitions and we
know the ESP isn't shared, it will be deleted with delete all.
Basic assumption here is that we assume ESP is in use if there's other
stuff on the system we don't know about. So it's a more defensive policy
than the current one.
If you really want to delete it, it'll moved to "Unknown" bucket and
then you can then hit the "-" button to delete it. Takes a little extra
effort, but still possible to delete, and you really are explicitly
demonstrating you want the ESP specifically gone at that point.
Note that this option is different than always keeping the ESPs in
unknown from the start (proposal #5,) because you get to see the ESP in
line with the OSes we know it's associated with before you do the delete
all action.
SUMMARY: adamw and mizmo think this is probably the best course of
action from a UX POV. jkon supports the patch too in the PR.
4) Simple string change in the dialog to warn users
----------------------------------------------------
Patch:
https://github.com/rhinstaller/anaconda/pull/377#issuecomment-144808251
<dlehman> let's just put a little warning text when removing an ESP (or
when removing anything) and leave it at that
SUMMARY: This requires people to read, and they aren't always good about
doing that.
5) Move ESPs to the Unknown Bucket
----------------------------------
<mizmo> then you wouldn't even have to special case unknown
<mizmo> because the esp wouldn't be under the fedora OS bucket anymore
so when you do delete all ... it doesnt get deleted
<mizmo> if there's a single unknown partition => all ESPs go to unknown
bucket
<mizmo> if there's more than one known OS => all ESPs go to unknown bucket
<mizmo> so ESP only shows up under an OS if it's unshared
downside: extra clicks to delete ESPs, but kind of good in that you
don't delete unless you're sure.
downside: potential for ending up with multiple ESPs if people don't use
the autopart button. (mizmo noted that in usability tests majority of
users did use autopart and then modified from there.)
downside: you never get to see the ESP associated with the OSes we know
it's associated with.
SUMMARY: Option #3 is just a better solution.
6) Do nothing
-------------
...
SUMMARY: There are two separate bug reports over this issue (BZ 1183880,
BZ 1177976) and the UX could stand some improvement so from my (mizmo)
UX POV I don't recommend this option. :)
Anyway, here are all the options and a rundown of what we were thinking
/ talked about with relation to this issue. It's up to the anaconda
development team how they would like to proceed, of course! Hopefully
this summary helps.
~m
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
