On Tue, 2015-10-13 at 16:46 -0400, 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 Hi, Is the ESP really so special? What about other shared filesystems? One could certainly have multiple linux installations that all use the same /home or /tunes or whatever. Should we schedule removal the first time the user asks us to remove one of these, or should we silently only remove it from the specified root in the UI until/unless they've removed it from the last root it's part of? I know the windows case is different in that the ESP is still shared even when the only root is "Unknown", but the rest seems to overlap. David > > ====== > > > 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-1448082 > 51 > > <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
