Re: Summary of shared EFI system partition discussion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi 
Please send credit card details

Or type stop to be deleted from my mailing list

Jamie
Sent from my iPhone

> On 14 Oct 2015, at 7:53 AM, Máirín Duffy <duffy@xxxxxxxxxx> wrote:
> 
> 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
>> 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




[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux