Re: Summary of shared EFI system partition discussion

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