Summary of shared EFI system partition discussion

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
[email protected]
https://www.redhat.com/mailman/listinfo/anaconda-devel-list