Not sure why I am continuously included on this thread Please ensure that you review your mail contacts to include only people relevant to conversation Cheers Sent from my iPhone > On 15 Oct 2015, at 1:14 AM, David Lehman <dlehman@xxxxxxxxxx> wrote: > >> 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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
