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=1183880We 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/377Put 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-cWhen '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 unshareddownside: 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
Attachment:
delete-all-parts.png
Description: PNG image
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
