I split this bug because here are two different bugs in one.
This bug represents missing multiselection feature in the Custom spoke.
+++ This bug was initially created as a clone of Bug #1183880 +++
Description of problem: dual-boot system, and reinstalling Fedora, custom installation permits the automatic deletion of the EFI System partition, rendering other installation(s) unbootable.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Dual boot Windows + Fedora 21 installation.
2. Launch Fedora installer, and go to custom partitioning.
3. Click on any partition listed under Fedora 21 installation, click minus (-) button to delete it, and check the box to apply this to all other partitions.
Deletes the EFI system partition, other OS's not being uninstalled are no longer bootable.
First, the EFI System partition shouldn't even be visible. Bug 1022316.
Second, the EFI System partition needs to be exempt from deletion unless all partitions are being delete. Otherwise, the installer needs to inform the user that the EFI System partition has been marked for deletion and any remaining OS's will become unbootable.
--- Additional comment from Chris Murphy on 2015-01-20 19:29:22 EST ---
Same behavior in anaconda-22.13.
--- Additional comment from Brian Lane on 2015-01-21 20:56:00 EST ---
"and check the box to apply this to all other partitions."
Don't do that if you want to keep the other partitions.
--- Additional comment from Chris Murphy on 2015-01-22 00:00:51 EST ---
So what you're saying is that I have to click 4 times to delete each "device" individually, rendering this checkbox completely useless on any UEFI dual boot (or more) system where a prior Fedora needs to be removed. That's rather indefensible.
Now, let's look at LVM thinp or Btrfs volumes which can have hundreds (in fact thousands) of snapshots. This UI absolutely does not scale. I'm getting carpal tunnel clicking *FOUR TIMES* just to delete one device, let alone every one of these snapshots.
The EFI System partition is not owned by Fedora alone. It is shared. It shouldn't be listed at all, but at the very least shouldn't be listed under a Fedora instance in multiboot cases.
--- Additional comment from Kamil Páral on 2015-05-25 09:25:33 EDT ---
I have to take sides with Chris, here. There are two issues:
1. ESP should not be automatically deleted if there are more than 1 OS installed to it (can we detect that?). I know that the error dialog speaks in terms of partitions, but the impression is "delete everything related to this OS", and that means something a bit different.
2. The current UI for deleting partitions does not allow multiselect. That makes deletion of multiple partitions an exercise, and renders thinp or btrfs management impossible.
One of the two would solve this issue.
--- Additional comment from David Shea on 2015-08-03 09:41:40 EDT ---
--- Additional comment from Chris Murphy on 2015-08-03 11:08:58 EDT ---
Effectively this is installer induced data loss. It's unreasonable to think the user knows this shared partition that Fedora didn't create is included in "all other partitions" because it's not a Fedora owned or created partition, nor does the UI convey this.
Basically a reinstall of Fedora 23 over Fedora 22 will break the bootability of Windows if the user checks "apply this to all other partitions". It's completely reasonable for them to pick that option and for it to not break Windows bootability.
--- Additional comment from Fedora Blocker Bugs Application on 2015-08-03 11:10:22 EDT ---
Proposed as a Blocker for 23-final by Fedora user chrismurphy using the blocker tracking app because:
On the basis the behavior causes silent destruction of necessary bootloader data to boot Windows when the user has indicated they want to keep Windows by having not deleting any Windows partitions:
"All known bugs that can cause corruption of user data must be fixed or documented at Common F23 bugs."
On on at least an implicit basis, the user has reason to expect that Windows can be booted by this criteria:
"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."
--- Additional comment from Petr Schindler on 2015-08-03 12:40:30 EDT ---
Discussed at today's blocker review meeting .
This bug was accepted as Final blocker - This bug is a violation of the following Final criterion: "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."
--- Additional comment from Petr Schindler on 2015-08-03 12:59:19 EDT ---
The reasoning for accepting this as a blocker is that installation of Fedora shouldn't break another installed systems (other then those chosen to be deleted). If there is a partition which is shared between multiple systems it shouldn't be listed under any of those in custom partitioning. Because less experienced users could think that deletion of all partitions under some system (e. g. Fedora) wouldn't lead to unbootable system they didn't touch (e. g. Windows).
If I want to delete a system and the UI gives me easy way to do it (delete all partitions listed under that system) I will do it because I expect that changes to those partitions won't touch another systems.
For more details please refer to logs of blocker review meeting. Thank you.
--- Additional comment from Jiri Konecny on 2015-09-23 07:10:25 EDT ---
we have had brainstorming in the anaconda team about this bug and we thought that this bug should be split into two bugs:
First that the user could delete existing EFI partition which could lead to unbootable system.
Second is the request for the multiselection feature.
So I'm cloning the bug to split it. The EFI partition bug should be a blocker but the multiselection bug shouldn't.
could you please remove blocker status from this bug. I think that the multiselection feature should be nice to have feature but it's not blocker.
It only has the status because you cloned it =) I generally find bug cloning to be almost always a bad idea, because of exactly this - you get an ugly bug with a gigantic first comment and a bunch of incorrect metadata. I usually just create the new bug from scratch.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.
More information and reason for this action is here:
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.
Per #c3, this was likely fixed back in F24 cycle.