Bug 1183880

Same behavior in anaconda-22.13.

"and check the box to apply this to all other partitions."

Don't do that if you want to keep the other partitions.

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.

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.

*** Bug 1177976 has been marked as a duplicate of this bug. ***

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.

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."

Discussed at today's blocker review meeting [1].

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."

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-08-03/

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.

Hello,

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.

PR: https://github.com/rhinstaller/anaconda/pull/377

(In reply to Petr Schindler from comment #8)
> Discussed at today's blocker review meeting [1].
> 
> 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."
> 
> [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-08-03/

(In reply to Petr Schindler from comment #9)
> 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.

This does not appear to be a correct evaluation. The issue is not one that happens with reclaiming space, nor with automatic partitioning.  This only happens if you are in custom partitioning, and you explicitly tell it to remove all related partitions.

While it's true there could be UI here that makes for a more convenient workflow, there is nothing here that prevents dual booting (as comment #8 says) or any *automatic* or non-manual removal of any shared resource.

This only happens if you ask anaconda to do it, and you can even do custom partitioning that reclaim space without the need to hit this.

This should not be considered a blocker.

For reference when we come to re-discuss this: the proposed fix for this - https://github.com/rhinstaller/anaconda/pull/377 - is a fairly large change which experience would suggest is quite likely to have some other problematic consequences.

There are various other possible approaches to deal with this - just don't ever display ESPs as 'part' of an OS, warn any time the 'remove all others in this root' thing would remove a partition that's part of *multiple* groups, etc etc - but I don't think anyone's proposed one yet which would clearly be a very safe fix.

So, that's a consideration at this point in the cycle.

Also for convenience, here's the log of the initial discussion:

https://meetbot.fedoraproject.org/fedora-blocker-review/2015-08-03/f23-blocker-review.2015-08-03-16.01.log.html

search for the bug # (1183880) to find the discussion. By my count the vote went:

<kinokoio> +1
<roshi> +1
...
<roshi> +1 punt
<kinokoio> +1 punt
...
<kinokoio> +1 blocker
<jkurik> I am +1 as well
<tflink> I'm also somewhat +1
<cmurf> doesn’t matter. I’d say block

so there was a lot of vacillating and eventually it got a sort of 'well, +1, I guess' vote which looked like people were expecting some pushback.

(In reply to Kamil Páral from comment #4)
> 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.

It is not automatic. You asked us, by checking the box, to remove them all.

How will someone delete a shared ESP if they really really understand the
implications, &c, if we do what you're asking here?

> 
> 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.

Assuming by "impossible" you mean "inconvenient" here. Multiple selection
would make things a bit nicer for the huge-number-of-snapshot cases.

> 
> One of the two would solve this issue.


(In reply to Chris Murphy from comment #6)
> 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.

What's unreasonable is to check a box that says "also remove all of the other
devices listed here" and then complain that one of them was removed. I am
in total disbelief at this nonsense.

> 
> 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.

If and only if the user TELLS US TO REMOVE ALL OF THEIR PARTITIONS. What part
of this is confusing?

The part that's confusing is that it's not hugely obvious that the partition in question is *also* part of another OS.

I don't think this needs to block release, but I *do* think it's a reasonable bug report. anaconda is doing quite a lot of abstraction here: it's taking a bunch of storage partitions and it's coming up with this story that some of them constitute 'part of' some operating system. Then it lets you view all the partitions that are 'part of' that OS together and delete them as a group. There's a fairly clear message being sent there, to me, and that message is 'by clicking here, you'll delete this OS'. And that is in fact what happens. The problem is it's not *all* that happens: you also break another OS. The UI doesn't really communicate that at all. (That's why I suggested 'warn when one of the volumes is also 'part of' another OS group' as another possible fix here).

I think it's reasonable to say that this could trip people up, and since it's anaconda that's doing all this 'THESE volumes are part of THIS OS' abstraction, it's kind of anaconda's responsibility to deal with the fallout of that.

The ancillary issue Chris mentions is also worth considering: because you can't say 'delete them all but not THIS one' and you can't delete them all then *undelete* the ESP, if the OS has a ton of volumes (e.g. snapshots) you don't really have any great choice, you have to painstakingly click on each volume and delete them one at a time.

(It's worth comparing to the guided resize/delete workflow where we *don't* do all this 'group partitions by OS' stuff, we just display the partitions).

Like I said I don't think it really needs to be a release blocker (my personal opinion is the wrong call was made on that at first), but I think it's reasonable to call this behaviour a bug.

If I hadn't been out of the office I would have promptly closed this as notabug since the entire problem is the incorrect assumption that you can ask us to remove every partition listed and expect us to do something other than that.

If the message could reasonably be interpreted as an indication of the kind of detailed consideration Chris is expecting here I might go the other way, but it doesn't. It says "Delete all other file systems in the ____ root as well". Which part of that indicates that some of the file systems will not be deleted?

It doesn't. The problem is that it's not at all obvious from the UI that there's going to be a *problem* with deleting them.

Just put yourself in the shoes of a user who has Windows and Fedora 22 installed and thinks: "OK, I want to delete F22 and replace it with F23 using LVM thinp" (or any other use case which requires use of custom partitioning).

What do you do? OK, you go into custom partitioning. And you see that it has these little groups: Windows, Fedora 22. Note the groups aren't *expanded* by default. You don't see what it's the Windows group.

So you think "OK, I want to delete Fedora 22", and you expand the Fedora 22 group. You select to delete the first partition, and it pops up this helpful little question - 'do you want to delete all the other Fedora 22 partitions too?' So you think, well, sure! Thanks, helpful little question! So you say "yes", and it goes right ahead, and you create the new F23 layout and complete the install.

At *no point* has there been any visual indication that one of the partitions you deleted was in fact crucial to the operation of Windows. The 'Windows' partition group is not expanded by default. There's no warning when you say "Yes" to the helpful question that one of the partitions was actually part of 'Windows' too. The problem isn't that the user didn't *really* want to delete all Fedora 22 partitions, he did. The problem is he didn't want to delete a partition that was used by *both* F22 and Windows, but there was just no clear indication that this was even happening.

There's the 'recap' dialog you see when you leave custom part, but that doesn't give you any kind of clear indication that one of the partitions selected for deletion was actually needed for Windows to work.

So you reboot, and now you find, crap, Windows doesn't boot and it's not at all trivial (or possible?) to fix it. This is bad.

Users who understand exactly how UEFI boot works, and that it's likely Windows and Fedora would be sharing an ESP, might catch this. I don't think that describes most users, even users who need/choose to go into custom partitioning (which, remember, we require for *anything* besides the default filesystem and container choice).

a. The ESP being listed only under Fedora is misleading and wrong
b. The UI/UX instantly is a failure, even in manual partition, when it expects the user to know what the function of an ESP is in order to avoid this bug.
c. The consequences directly, clearly, violate both data loss and dual boot criteria. The user will have to get this fixed somehow, and I don't know for sure that Windows Startup Repair can fix it. I already think it's a self-evident blocker on the face of it, but if Startup Repair can't fix it, it's truly an egregious bug.

Conclusion, the current behavior throws the user under a bus, blames them for its mistake, and then also has a confused developer opining that users shouldn't be confused about any of this (as glorious double standard icing on the cake). This is still a GUI installer, and a GUI installer's primary mandate of advocating for the user is wholesale abandoned with this bug.

(In reply to Peter Jones from comment #12)
> This should not be considered a blocker.

This is specious reasoning that depends on the inappropriate expectation the user should know what an ESPs function is, and the consequences of deleting it. Both blocker review understood that in determining it was a blocker; and in c10 anaconda team has already discussed this and agreed it's a blocker.

That's not what they meant by #c10. They were simply splitting the part that had been approved as a blocker by the blocker review meeting from the part which had not. It was not intended to signal agreement or disagreement with the decision (I have this from anaconda team).

OK well I'm going on what was stated which is unambiguous, "The EFI partition bug should be a blocker but the multiselection bug shouldn't."

(In reply to awilliam from comment #18)
> It doesn't. The problem is that it's not at all obvious from the UI that
> there's going to be a *problem* with deleting them.
> 
> Just put yourself in the shoes of a user who has Windows and Fedora 22
> installed and thinks: "OK, I want to delete F22 and replace it with F23
> using LVM thinp" (or any other use case which requires use of custom
> partitioning).
Yeah, I think this is definitely a significant use-case and the current design really makes it very easy to shoot your foot off. And I can see quite some "Fedora ate my Windows/Gentoo/Ubuntu" showing up as a result, especially due to the general trend of more and more installations being performed in the EFI mode.

I think the patch proposed in comment 11 solves the issue quite nicely by moving the efi partition to a separate group if multiple OSes are detected. So at least from my point of view I would suggest to go with the patch for F23, provided enough testing could be done on it to assure it works correctly.

As for multi-selection and other tweaks in the custom spoke - while indeed important I think that's indeed out of scope for F23.

small addendum to #c18 - now I've tested it I see that anaconda doesn't detect Windows installs (they just go to Unknown), so it provides literally no cue that the partition is of significance to the Windows install, even a hidden one.

That unfortunately also means the simpler fix I was working on won't fly, because it relied on anaconda knowing the partition was part of another OS. :/

(In reply to awilliam from comment #24)
> small addendum to #c18 - now I've tested it I see that anaconda doesn't
> detect Windows installs (they just go to Unknown), so it provides literally
> no cue that the partition is of significance to the Windows install, even a
> hidden one.
> 
> That unfortunately also means the simpler fix I was working on won't fly,
> because it relied on anaconda knowing the partition was part of another OS.
> :/

Yeah that is why I'm moving all EFI partitions when some unknown partition shows up.

(In reply to Chris Murphy from comment #22)
> OK well I'm going on what was stated which is unambiguous, "The EFI
> partition bug should be a blocker but the multiselection bug shouldn't."

Well I thought that this bug might be or could be a blocker but the second one is not a blocker because it's more cosmetic and it's not blocking installation in any way. Sorry for misunderstanding.

So I made a ShakyCam video to hopefully explain clearly the problem here:

https://www.youtube.com/watch?v=PcUd4K0iM6c

Discussed at 2015-10-05 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-10-05/f23-blocker-review.2015-10-05-16.00.html .

After lengthy discussion this was rejected as a blocker but accepted as a freeze exception issue. It would be difficult and potentially misleading to summarize the entire discussion briefly, so please refer to the full log:

https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-10-05/f23-blocker-review.2015-10-05-16.00.log.html

for context.

New PR: https://github.com/rhinstaller/anaconda/pull/410

For posterity: writeup of the issue and the proposed solutions we discussed

https://www.redhat.com/archives/anaconda-devel-list/2015-October/msg00000.html

Pushed hotfix to Fedora 23.

This hotfix changing label to warn user bad things could happen.
https://github.com/rhinstaller/anaconda/pull/410

Main patch with more bulletproof fix will go to rawhide later.

anaconda-23.19.8-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-cad91ea1ae

anaconda-23.19.8-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update anaconda'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-cad91ea1ae

python-blivet-1.12.8-1.fc23 anaconda-23.19.9-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-da7ada8825

anaconda-23.19.10-1.fc23, python-blivet-1.12.8-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update anaconda python-blivet'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-da7ada8825

anaconda-23.19.10-1.fc23, python-blivet-1.12.8-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.