Summary of shared EFI system partition discussion

[Máirín Duffy]

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:

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

- Fedora/Fedora:

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

[Máirín Duffy]

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

Post by Máirín Duffy
Hi,
A couple of weeks ago this bug / issue was brought to my attention since
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.
======
- 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
======
===================
adamw helpfully made a screencast of the issue, which I'll describe here
http://youtu.be/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.
======================
- 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
===================
(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.
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)
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'
-----------------------------------------------------------------
https://github.com/rhinstaller/anaconda/pull/383
- Windows/Fedora: http://youtu.be/e4PIOf8K538
- Fedora/Fedora: http://youtu.be/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
----------------------------------------------------
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
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Jamie Stephenson]

Hi
Please send credit card details

Or type stop to be deleted from my mailing list

Jamie
Sent from my iPhone

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

Post by Máirín Duffy
Hi,
A couple of weeks ago this bug / issue was brought to my attention since
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.
======
- 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
======
===================
adamw helpfully made a screencast of the issue, which I'll describe here
http://youtu.be/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.
======================
- 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
===================
(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.
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)
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'
-----------------------------------------------------------------
https://github.com/rhinstaller/anaconda/pull/383
- Windows/Fedora: http://youtu.be/e4PIOf8K538
- Fedora/Fedora: http://youtu.be/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
----------------------------------------------------
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
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Jiří Konečný]

Hello,

thank you for this nice summary. Yesterday I have sent an email to get
final decision in our team which of these solutions we will use to
Fedora 23. Seems like most of us (including me) agreed on small string
change #4.

Post by Máirín Duffy
===================
(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.
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.

I agree with you. I think this will be nice way for the final patch to
Fedora 24 but not now in final freeze of F23.

Post by Máirín Duffy
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)
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.

IMHO I don't like this solution. It seems complicated to me. I think
hiding a partition is not the right way.

Post by Máirín Duffy
3) Silently fail to delete ESPs when user checks off 'delete all'
-----------------------------------------------------------------
https://github.com/rhinstaller/anaconda/pull/383
- Windows/Fedora: http://youtu.be/e4PIOf8K538
- Fedora/Fedora: http://youtu.be/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.

When I looked on this in more detail I'm afraid it's also big change to
the code, for true this looks to me more invasive then my first patch
now.
Parts of this PR could be used as final patch though.

Post by Máirín Duffy
4) Simple string change in the dialog to warn users
----------------------------------------------------
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.

This seems to us as the best solution for the F23. It isn't invasive at
all and the user will be warned.
You are right when you said user didn't read but when you take in count
number of bugs with this issue to this date it seems most of the users
are not affected (not so many PCs are using UEFI now). This could help
some users before they do it wrong.

I'm more afraid of users which are used to this behavior and you change
it without any warning when you take in count how long this is standard
behavior of Fedora.

Post by Máirín Duffy
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.

I don't think this is the right way.

Post by Máirín Duffy
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. :)

I don't recommend it either.

Post by Máirín Duffy
_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Jamie Stephenson]

Hi
Please send credit card details

Or type stop to be deleted from my mailing list

Jamie
Sent from my iPhone

Post by Jiří Konečný
Hello,
thank you for this nice summary. Yesterday I have sent an email to get
final decision in our team which of these solutions we will use to
Fedora 23. Seems like most of us (including me) agreed on small string
change #4.

Post by Máirín Duffy
===================
(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.
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.

I agree with you. I think this will be nice way for the final patch to
Fedora 24 but not now in final freeze of F23.

Post by Máirín Duffy
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)
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.

IMHO I don't like this solution. It seems complicated to me. I think
hiding a partition is not the right way.

Post by Máirín Duffy
3) Silently fail to delete ESPs when user checks off 'delete all'
-----------------------------------------------------------------
https://github.com/rhinstaller/anaconda/pull/383
- Windows/Fedora: http://youtu.be/e4PIOf8K538
- Fedora/Fedora: http://youtu.be/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.

When I looked on this in more detail I'm afraid it's also big change to
the code, for true this looks to me more invasive then my first patch
now.
Parts of this PR could be used as final patch though.

Post by Máirín Duffy
4) Simple string change in the dialog to warn users
----------------------------------------------------
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.

This seems to us as the best solution for the F23. It isn't invasive at
all and the user will be warned.
You are right when you said user didn't read but when you take in count
number of bugs with this issue to this date it seems most of the users
are not affected (not so many PCs are using UEFI now). This could help
some users before they do it wrong.
I'm more afraid of users which are used to this behavior and you change
it without any warning when you take in count how long this is standard
behavior of Fedora.

Post by Máirín Duffy
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.

I don't think this is the right way.

Post by Máirín Duffy
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. :)

I don't recommend it either.

Post by Máirín Duffy
_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Jamie Stephenson]

Hi please follow this link
Www.downloadafreevirus.com/yourcomputerwillcrash

If you don't want to be on my mailing list,
Please reply with this exact phrase "I'm a spammer who is annoying Jamie"

Regards

Jamie



Sent from my iPhone

Post by Jiří Konečný
Hello,
thank you for this nice summary. Yesterday I have sent an email to get
final decision in our team which of these solutions we will use to
Fedora 23. Seems like most of us (including me) agreed on small string
change #4.

Post by Máirín Duffy
===================
(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.
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.

I agree with you. I think this will be nice way for the final patch to
Fedora 24 but not now in final freeze of F23.

Post by Máirín Duffy
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)
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.

IMHO I don't like this solution. It seems complicated to me. I think
hiding a partition is not the right way.

Post by Máirín Duffy
3) Silently fail to delete ESPs when user checks off 'delete all'
-----------------------------------------------------------------
https://github.com/rhinstaller/anaconda/pull/383
- Windows/Fedora: http://youtu.be/e4PIOf8K538
- Fedora/Fedora: http://youtu.be/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.

When I looked on this in more detail I'm afraid it's also big change to
the code, for true this looks to me more invasive then my first patch
now.
Parts of this PR could be used as final patch though.

Post by Máirín Duffy
4) Simple string change in the dialog to warn users
----------------------------------------------------
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.

This seems to us as the best solution for the F23. It isn't invasive at
all and the user will be warned.
You are right when you said user didn't read but when you take in count
number of bugs with this issue to this date it seems most of the users
are not affected (not so many PCs are using UEFI now). This could help
some users before they do it wrong.
I'm more afraid of users which are used to this behavior and you change
it without any warning when you take in count how long this is standard
behavior of Fedora.

Post by Máirín Duffy
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.

I don't think this is the right way.

Post by Máirín Duffy
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. :)

I don't recommend it either.

Post by Máirín Duffy
_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Adam Williamson]

Post by Jiří Konečný
When I looked on this in more detail I'm afraid it's also big change to
the code, for true this looks to me more invasive then my first patch
now.
Parts of this PR could be used as final patch though.

I'm curious - what makes it a big change?

[Leslie S Satenstein]

Hi Adam
Your experience with anaconda peaked my own curiosity and since I had /dev/sda with W8.1 and
F23 on /dev/sdc, I asked myself what would I experience if I choose those two disks, targeting /dev/sdc  as an overwrite of the existing Fedora23.
With the selection pane, I got to see both a windows /dev/sda without seeing the 350meg system reserved   partition) and the F23 partitions. Results as you explained.
Not wanting to actually do a reinstall,  I choose to abort anaconda, but was unable to do it from within the selection pane. (could not quit or return back).  I did a shutdown from the host live F23 image. 

Here is the problem I encountered.

I was using a live ISO image to test, and therefore clicked on the shutdown icon for the live iso, which also kills anaconda.
On reboot,  /dev/sd6 (/boot) was corrupted.  I could not boot into the original F23 as F23's /boot appeared active (mounted).


I thought the rule was that anaconda would not touch any disks until the confirmation to install "button" was clicked.  Was it anaconda that caused the problem, or quitting via requesting shutdown the hosting live F23 system?

It took a rescue disk to run a check and correct against the /boot, after which the original /dev/sdc F23 beta-rc1 was bootable.
Questions
Should a bug against anaconda be raised to indicate that within the partition assignment, the back button must always be actived?   Should a bug be raised to indicate the method in which /boot was corrupted?
If not me to do so, can you duplicate and confirm my findings. 
 Regards
 Leslie
Mr. Leslie Satenstein
Montréal Québec, Canada



From: Adam Williamson <***@redhat.com>
To: Discussion of Development and Customization of the Red Hat Linux Installer <anaconda-devel-***@redhat.com>
Sent: Wednesday, October 14, 2015 11:59 AM
Subject: Re: Summary of shared EFI system partition discussion

Post by Jiří Konečný
When I looked on this in more detail I'm afraid it's also big change to
the code, for true this looks to me more invasive then my first patch
now.
Parts of this PR could be used as final patch though.

I'm curious - what makes it a big change?

[Jiří Konečný]

Hello

I think it's big change now (in freeze) not as whole (same for the my
first patch). As I said it's really nice base for the final but I don't
like to break something else by this bug now.

If you want specific parts:
- New import
- 2 files change (dialog change)
- Change of storage playground

But IMHO this can't be measured I think it's more personal opinion than
anything else.

Post by Adam Williamson

Post by Jiří Konečný
When I looked on this in more detail I'm afraid it's also big
change
to
the code, for true this looks to me more invasive then my first patch
now.
Parts of this PR could be used as final patch though.

I'm curious - what makes it a big change?

[David Lehman]

Post by Máirín Duffy
Hi,
A couple of weeks ago this bug / issue was brought to my attention since
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.
======
- 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

Post by Máirín Duffy
======
===================
adamw helpfully made a screencast of the issue, which I'll describe here
http://youtu.be/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.
======================
- 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
===================
(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.
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)
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'
-----------------------------------------------------------------
https://github.com/rhinstaller/anaconda/pull/383
- Windows/Fedora: http://youtu.be/e4PIOf8K538
- Fedora/Fedora: http://youtu.be/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
----------------------------------------------------
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
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Jamie Stephenson]

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

Post by David Lehman

Post by Máirín Duffy
Hi,
A couple of weeks ago this bug / issue was brought to my attention since
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.
======
- 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

Post by Máirín Duffy
======
===================
adamw helpfully made a screencast of the issue, which I'll describe here
http://youtu.be/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.
======================
- 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
===================
(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.
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)
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'
-----------------------------------------------------------------
https://github.com/rhinstaller/anaconda/pull/383
- Windows/Fedora: http://youtu.be/e4PIOf8K538
- Fedora/Fedora: http://youtu.be/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
----------------------------------------------------
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
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Máirín Duffy]

Hi,

Post by David Lehman
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.

I think ESP is special in that, if you have multiboot with shared
filesystems that aren't ESP, you probably put that in place yourself so
you should be well aware of your own setup. But Anaconda by default
shares any existing ESPs if you don't do custom install, so we do that
for you and you don't opt in (if that makes sense.)

I also think other shared filesystems are more likely to be data. We do
separate data partitions from system ones in the list...

It would be *nice* to have some kind of affordance around shared data
partitions if we knew they were shared, but I don't know that we do?

~m

[David Lehman]

Post by Máirín Duffy
Hi,

Post by David Lehman
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.

I think ESP is special in that, if you have multiboot with shared
filesystems that aren't ESP, you probably put that in place yourself so
you should be well aware of your own setup. But Anaconda by default
shares any existing ESPs if you don't do custom install, so we do that
for you and you don't opt in (if that makes sense.)
I also think other shared filesystems are more likely to be data. We do
separate data partitions from system ones in the list...
It would be *nice* to have some kind of affordance around shared data
partitions if we knew they were shared, but I don't know that we do?

I think we've established pretty firmly that users cannot be expected
to know (or think about) their setups when clicking buttons during
installation.

David

Post by Máirín Duffy
~m
_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Jamie Stephenson]

Hi
Please send credit card details

Or type stop to be deleted from my mailing list

Jamie
Sent from my iPhone

Post by David Lehman

Post by Máirín Duffy
Hi,
A couple of weeks ago this bug / issue was brought to my attention since
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.
======
- 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

Post by Máirín Duffy
======
===================
adamw helpfully made a screencast of the issue, which I'll describe here
http://youtu.be/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.
======================
- 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
===================
(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.
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)
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'
-----------------------------------------------------------------
https://github.com/rhinstaller/anaconda/pull/383
- Windows/Fedora: http://youtu.be/e4PIOf8K538
- Fedora/Fedora: http://youtu.be/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
----------------------------------------------------
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
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Jamie Stephenson]

Hi
Please send credit card details

Or type stop to be deleted from my mailing list

Jamie
Sent from my iPhone

Post by David Lehman

Post by Máirín Duffy
Hi,
A couple of weeks ago this bug / issue was brought to my attention since
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.
======
- 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

Post by Máirín Duffy
======
===================
adamw helpfully made a screencast of the issue, which I'll describe here
http://youtu.be/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.
======================
- 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
===================
(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.
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)
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'
-----------------------------------------------------------------
https://github.com/rhinstaller/anaconda/pull/383
- Windows/Fedora: http://youtu.be/e4PIOf8K538
- Fedora/Fedora: http://youtu.be/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
----------------------------------------------------
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
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Jamie Stephenson]

Hi

Tired of brushing your teeth

Then stop.... They have dentist for a reason

See www.badteeth.com

To unsubscribe, please go to www.instantvirusdownload.com

Regards

Jamie
Sent from my iPhone

Post by David Lehman

Post by Máirín Duffy
Hi,
A couple of weeks ago this bug / issue was brought to my attention since
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.
======
- 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

Post by Máirín Duffy
======
===================
adamw helpfully made a screencast of the issue, which I'll describe here
http://youtu.be/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.
======================
- 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
===================
(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.
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)
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'
-----------------------------------------------------------------
https://github.com/rhinstaller/anaconda/pull/383
- Windows/Fedora: http://youtu.be/e4PIOf8K538
- Fedora/Fedora: http://youtu.be/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
----------------------------------------------------
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
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Jamie Stephenson]

Hi please follow this link
Www.downloadafreevirus.com/yourcomputerwillcrash

If you don't want to be on my mailing list,
Please reply with this exact phrase "I'm a spammer who is annoying Jamie"

Regards

Jamie
Sent from my iPhone

Post by David Lehman

Post by Máirín Duffy
Hi,
A couple of weeks ago this bug / issue was brought to my attention since
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.
======
- 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

Post by Máirín Duffy
======
===================
adamw helpfully made a screencast of the issue, which I'll describe here
http://youtu.be/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.
======================
- 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
===================
(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.
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)
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'
-----------------------------------------------------------------
https://github.com/rhinstaller/anaconda/pull/383
- Windows/Fedora: http://youtu.be/e4PIOf8K538
- Fedora/Fedora: http://youtu.be/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
----------------------------------------------------
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
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Adam Williamson]

Post by David Lehman

Post by Máirín Duffy
Hi,
A couple of weeks ago this bug / issue was brought to my attention since
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.
======
- 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.

My patch actually handles all shared partitions the same way. The
second demo video is not using an ESP, if you look carefully. The logic
is that the 'delete all' button only deletes volumes that *only* appear
in the bucket it's being used on, and additionally does not delete boot
partitions if there are *any* 'unknown' partitions. (The text label was
updated to reflect this).

So if you have a volume shared between three Linux installs A, B and C,
after clicking the 'delete all' button for A, it'll still be present in
B and C; after clicking the 'delete all' button for B it'll still be
present in C; after clicking the 'delete all' button for C it goes
away.

You can always delete a shared partition by targeting it
*specifically*, though. It might be good to have a warning for that
case.

[Chris Murphy]

Post by Máirín Duffy
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)

No such users exist anywhere in the Windows or OS X world where the ESP is
always hidden in GUI partitioning programs (not merely hidden in their OS
installer).

Linux users have always been easily convinced that MBR gaps, BIOSBoot, and
ESPs are functionally identical things, and they do not care one bit that
they can't see, create, modify, delete MBR gaps. So why do they care about
this with BIOSBoot and ESP? The answer has been, crickets.



3) Silently fail to delete ESPs when user checks off 'delete all'



I think this is a reasonable 2nd best handling option. Considering it's
more work to rip out what's already been done, practically speaking it may
be the 1st best option. There will probably be a future where all of these
100MB ESPs floating around are too small, and we're going to want a behind
the scenes way of dealing with this no matter automatic or custom
partitioning, and the existing ESP UI/UX can be ripped out then. That's a
lot more than 2 or 3 Fedora releases away.


All the other options enhance confusion by merely rearranging the deck
chairs, or add more dialogs, and more translation requirements, and more
potential for bugs. The real "problem" here, is the user who has always
been, and forever will be, ignorant of bootloader blocks. There is no
amount of education or documentation or oops I can't boot my computer
experiences, that will change that so we need to give up on the idea of
trying to make users better than they are and just let them get on with why
they're installing Fedora in the first place.

[Máirín Duffy]

Hi Chris,

Post by Chris Murphy
The real "problem" here, is the user who has always
been, and forever will be, ignorant of bootloader blocks. There is no
amount of education or documentation or oops I can't boot my computer
experiences, that will change that so we need to give up on the idea of
trying to make users better than they are and just let them get on with
why they're installing Fedora in the first place.

To be fair - many of the users who are ignorant of bootloader blocks are
also ignorant of why they'd want to go beyond the default FS / partition
layout choices and wouldn't end up in custom partitioning anyway. This
issue does not affect guided storage path nor the reclaim disk space dialog.

~m

[Chris Murphy]

Post by Máirín Duffy
Hi Chris,

Post by Chris Murphy
The real "problem" here, is the user who has always
been, and forever will be, ignorant of bootloader blocks. There is no
amount of education or documentation or oops I can't boot my computer
experiences, that will change that so we need to give up on the idea of
trying to make users better than they are and just let them get on with
why they're installing Fedora in the first place.

To be fair - many of the users who are ignorant of bootloader blocks are
also ignorant of why they'd want to go beyond the default FS / partition
layout choices and wouldn't end up in custom partitioning anyway.

I see no such correlation. I routinely see users who only have ever used
custom partitioning (not just Anaconda, but other distro installers as
well) have no idea what firmware their computer has, why that matters, how
it affects what partition scheme is used, what partitions are created, the
fact that grub2-install no longer applies, myriad changes that are thrust
upon the user as a result of not so much the UEFI spec but because of this
very weird (to me) installer idea that users need to see all partitions
just because that's they way it's always been.

And by so doing, they are now getting into trouble in ways they never
previously got into trouble. And in ways they don't get into trouble with
other OS partitioning tools that don't show them the whole story.

Post by Máirín Duffy
This issue does not affect guided storage path nor the reclaim disk space
dialog.

This issue does not affect custom partitioning with MBR gaps either. That
is, it doesn't happen on BIOS+MBR systems. The user cannot delete the
Windows bootloader even in custom partitioning on such systems. They
literally can't get into trouble.

Replicate that behavior, is what I'm suggesting, rather than falling into
this trap of showing partitions for the sake of showing partitions, when
doing so does not aid user success.

The consequence of showing them such things is that we're effectively
telling users for the first time in free software OS installer history they
need to understand how Windows boots. They never had to understand the
Windows bootloader esoterics before, but now they do, in order to avoid
trouble in custom partitioning. And that's not a ding on just Anaconda, all
the other distributions do this too by exposing these bootloader structures
to the user. And confusion ensues.

The appropriate thing to do for all users is totally abstract bootloader
blocks, however they manifest, and just manage it for them correctly. It's
the only way to be sure. Leave the user out of it, they're not reliable.

[Máirín Duffy]

Post by Máirín Duffy
To be fair - many of the users who are ignorant of bootloader blocks
are also ignorant of why they'd want to go beyond the default FS /
partition layout choices and wouldn't end up in custom partitioning
anyway.
I see no such correlation. I routinely see users who only have ever used
custom partitioning (not just Anaconda, but other distro installers as
well)

You can't really compare our install setup to other distros at this
point. It's too different.

The body of people installing their own distros today is also not the
same body of people who are generally ignorant of bootloader blocks
(that population is much, much larger) and it is also not where Fedora
can (or should) grow as a distribution given a mission to spread
software freedom. (If you've already got it, it's not getting spread if
you use it.)

There are *plenty* of people using the installer who don't use the
custom partitioning feature, and they are blissfully ignorant of
bootloader blocks and many other technical details I think the user
population you're thinking of are quite aware of.

Post by Máirín Duffy
have no idea what firmware their computer has, why that matters,
how it affects what partition scheme is used, what partitions are
created, the fact that grub2-install no longer applies, myriad changes
that are thrust upon the user as a result of not so much the UEFI spec
but because of this very weird (to me) installer idea that users need to
see all partitions just because that's they way it's always been.
And by so doing, they are now getting into trouble in ways they never
previously got into trouble. And in ways they don't get into trouble
with other OS partitioning tools that don't show them the whole story.

It's just a new way to get into trouble. There's tons of other ways to
get into trouble in any partition editing scenario that would remain if
we hid ESPs, but because they've been there longer they're harder to get
rid of and their removal would most certainly piss populations of users off.

(see
https://fedoraproject.org/wiki/User:Duffy/FundamentalTheoremOfDevelopingFLOSS
#1 and #5 particularly)

If a user doesn't want to see all the partitions - they shouldn't use
the custom partitioning tool. If they want to work with partitions but
don't like how anaconda displays them, they certainly have the knowledge
and capability to use a 3rd party partitioning tool to do exactly what
they want. Remember that anaconda's primary directive here is to install
the operating system, not to be a general purpose partition manager.

Post by Máirín Duffy
This issue does not affect guided storage path nor the reclaim disk
space dialog.
This issue does not affect custom partitioning with MBR gaps either.
That is, it doesn't happen on BIOS+MBR systems. The user cannot delete
the Windows bootloader even in custom partitioning on such systems. They
literally can't get into trouble.

Actually they can, and I have in the past. They could overwrite the MBR.
I believe part of the redesign involved making that no longer possible,
but for many years it was possible to wipe out your ability to boot windows.

Post by Máirín Duffy
Replicate that behavior, is what I'm suggesting, rather than falling
into this trap of showing partitions for the sake of showing partitions,
when doing so does not aid user success.

I think we need a lot more info/research into how that might affect
folks before we can safely do something like that. I agree in principle
generally with what you're suggesting, but the devil is certainly in the
details. Aren't MBRs are a lot smaller on disk than ESPs?; if there
isn't an ability to evaluate space taken up by ESPs and offer their
management as an option in custom part, would we (for random potentially
stupid example) be hurting some embedded users with very limited storage
capacity? This isn't a simple change and needs to be considered a bit
more deeply.

Post by Máirín Duffy
The consequence of showing them such things is that we're effectively
telling users for the first time in free software OS installer history
they need to understand how Windows boots. They never had to understand
the Windows bootloader esoterics before,

Again, they absolutely had to. Your last sentence there is absolutely
untrue. I have had to manually set up a bootloader to access a Windows
install I unwittingly rendered unbootable via a Linux multiboot
installation before. Multiple times. Multiple distros.

Post by Máirín Duffy
but now they do, in order to
avoid trouble in custom partitioning. And that's not a ding on just
Anaconda, all the other distributions do this too by exposing these
bootloader structures to the user. And confusion ensues.

This all affects folks in multi-boot scenarios, which are the majority
case nor really should they be. In 2015 this is an extremely limited
user population we're talking about here: an edge case.

Post by Máirín Duffy
The appropriate thing to do for all users is totally abstract bootloader
blocks, however they manifest, and just manage it for them correctly.
It's the only way to be sure. Leave the user out of it, they're not
reliable.

~m

[Chris Murphy]

Post by Máirín Duffy
To be fair - many of the users who are ignorant of bootloader blocks
are also ignorant of why they'd want to go beyond the default FS /
partition layout choices and wouldn't end up in custom partitioning
anyway.
I see no such correlation. I routinely see users who only have ever used
custom partitioning (not just Anaconda, but other distro installers as
well)

You can't really compare our install setup to other distros at this point.
It's too different.
The body of people installing their own distros today is also not the same
body of people who are generally ignorant of bootloader blocks (that
population is much, much larger) and it is also not where Fedora can (or
should) grow as a distribution given a mission to spread software freedom.
(If you've already got it, it's not getting spread if you use it.)
There are *plenty* of people using the installer who don't use the custom
partitioning feature, and they are blissfully ignorant of bootloader blocks
and many other technical details I think the user population you're thinking
of are quite aware of.

I'm not comparing installation setups among distros. I'm questioning
the assertion that users ignorant of bootloader esoterics are somehow
less likely to use custom partitioning. I see sufficient evidence to
the contrary.

The desire for a user to have a separate /var volume, a larger /
volume than default, or an /opt volume, is completely orthogonal to
bootloader knowledge.

As a matter of where to spend limited resources, you'll get no
argument from me that it should be in making the automatic path as
bulletproof as possible.

Post by Máirín Duffy
have no idea what firmware their computer has, why that matters,
how it affects what partition scheme is used, what partitions are
created, the fact that grub2-install no longer applies, myriad changes
that are thrust upon the user as a result of not so much the UEFI spec
but because of this very weird (to me) installer idea that users need to
see all partitions just because that's they way it's always been.
And by so doing, they are now getting into trouble in ways they never
previously got into trouble. And in ways they don't get into trouble
with other OS partitioning tools that don't show them the whole story.

It's just a new way to get into trouble. There's tons of other ways to get
into trouble in any partition editing scenario that would remain if we hid
ESPs, but because they've been there longer they're harder to get rid of and
their removal would most certainly piss populations of users off.

I think it's a new old way to get into trouble. Since it's not a user
serviceable part, don't point it out. Old axiom.

(see
https://fedoraproject.org/wiki/User:Duffy/FundamentalTheoremOfDevelopingFLOSS
#1 and #5 particularly)

Ok I'll be one of the last people to encourage these things as
theories or axioms. They might be humorously true, but they're bad
behaviors to coddle in users as if there's some entitlement to old
boogers we've finally flicked off.

Angry users have much difficulty explaining their use case in relation
to how UI inhibits arrival at their goal, yet somehow they have no end
of solutions for the problem, those being pretty much always terrible
even when the use case is legitimate.

If a user doesn't want to see all the partitions - they shouldn't use the
custom partitioning tool.

Oh I'm not saying the user doesn't want to see all. I'm saying they
either don't know what they want, or what they want is flawed.

There is no obligation to show them all just because it's custom
partitioning - this is provable by the existence of two custom
partitioning GUI tools used by millions of users that do not show
ESPs, always creates them at the time the drive is GPT partitioned
just in case something needs an ESP on that drive one day. And the
user complaints they can't see these hidden partitions? It's zero.

Meanwhile in just the redhat bugzilla, and the Fedora users lists and
forums, there are nearly a dozen bugs and must be hundreds of emails
demonstrating sufficient problems and confusion directly from showing
BIOSboot and ESP to users.

If they want to work with partitions but don't
like how anaconda displays them, they certainly have the knowledge and
capability to use a 3rd party partitioning tool to do exactly what they
want. Remember that anaconda's primary directive here is to install the
operating system, not to be a general purpose partition manager.

Ok but this is my argument. If they want to see all partitions, CLI
tools do that now. There is literally no advantage, and yet Exhibits
A, B, C, D, and so on, disadvantages to showing users these bootloader
partitions. That will not change. They will not get better at this
over time.

Post by Máirín Duffy
This issue does not affect custom partitioning with MBR gaps either.
That is, it doesn't happen on BIOS+MBR systems. The user cannot delete
the Windows bootloader even in custom partitioning on such systems. They
literally can't get into trouble.

Actually they can, and I have in the past. They could overwrite the MBR. I
believe part of the redesign involved making that no longer possible, but
for many years it was possible to wipe out your ability to boot windows.

a. I'm not arguing what can or could happen. I'm arguing what does and
does not happen. On UEFI the problem always happens when following the
reproduce steps. On BIOS the problem never happens when following the
reproduce steps.

b. On BIOS installations the Windows bootloader is on the Windows
system volume, so unless the user obliterates that system volume, they
aren't actually deleting the Windows bootloader because it's not on a
shared volume.

c. The jump code in the MBR is always overwritten in proper dual boot
installations because we need to jump to GRUB instead of jumping to
the Windows bootloader. This is normal, expected, and overwhelmingly
it works correctly. When it doesn't, it's an edge case or a bug.

What's completely new here is the user needs to know that the ESP
specifically contains the Windows bootloader, and deleting that
partition will render Windows unbootable. And that should not be
prerequisite knowledge to avoid nerfing Windows bootability while
using custom partitioning. Really.

Post by Máirín Duffy
Replicate that behavior, is what I'm suggesting, rather than falling
into this trap of showing partitions for the sake of showing partitions,
when doing so does not aid user success.

I think we need a lot more info/research into how that might affect folks
before we can safely do something like that.

What's the problem with just extrapolating from Apple's Disk Utility,
and the Windows Explorer? That's how you partition and format drives
on respective OS's, and neither of them show ESPs, ever. OS X for over
a decade. No one complains about what they can't see!

How much more research is necessary to know that not showing ESPs is
not a problem?

I agree in principle generally
with what you're suggesting, but the devil is certainly in the details.
Aren't MBRs are a lot smaller on disk than ESPs?;

MBR gap is now 1 MiB. But so is BIOSBoot yet that is shown. And
neither MBR gaps nor BIOSBoot are mountable, yet one is shown and the
other isn't. There really is a totally specious attachment to showing
the actual partition table in the GUI is all I can't discern here. Not
that it's actually useful information or a good idea.

ESPs have a range in practice. Microsoft OEMs have been creating them
100MB. Apple did for a while. Now they're in the 200-250MB realm for
most everyone.

if there isn't an ability
to evaluate space taken up by ESPs and offer their management as an option
in custom part, would we (for random potentially stupid example) be hurting
some embedded users with very limited storage capacity? This isn't a simple
change and needs to be considered a bit more deeply.

I agree I'm being x86_64 centric.

If we'd hurt embedded users by hiding the ESP in custom, we're also
hurting them with the wrong default in automatic. So their respective
WG or SIG needs to do the necessary customization to make sure the ESP
size default is set for that arch, I'm pretty sure that's possible
now.

Post by Máirín Duffy
The consequence of showing them such things is that we're effectively
telling users for the first time in free software OS installer history
they need to understand how Windows boots. They never had to understand
the Windows bootloader esoterics before,

Again, they absolutely had to. Your last sentence there is absolutely
untrue. I have had to manually set up a bootloader to access a Windows
install I unwittingly rendered unbootable via a Linux multiboot installation
before. Multiple times. Multiple distros.

I honestly have no idea what you're talking about. I've only done
several hundred Fedora installations after Windows XP, Vista, 8 and 10
and in every case Fedora did the right thing, except when it didn't
and in every case it didn't it was a legitimate bug. So no the user
doesn't have to know about chainloading and where the Windows
bootloader is located - Windows users don't even know that stuff.

You're apparently talking about something that breaks and *then* you
have to know esoterics. I'm saying now with this current behavior and
bug under discussion you need to know esoterics to avoid breaking
Windows, that's how easy it is to break it.

Post by Máirín Duffy
but now they do, in order to
avoid trouble in custom partitioning. And that's not a ding on just
Anaconda, all the other distributions do this too by exposing these
bootloader structures to the user. And confusion ensues.

This all affects folks in multi-boot scenarios, which are the majority case
nor really should they be. In 2015 this is an extremely limited user
population we're talking about here: an edge case.

I agree with that. I've asked the Desktop WG if they want to be more
permissive with dual boot and that's a no. There were multiboot (3+)
discussions in QA a while back and that was soundly rejected as
nuttastic, and the user is on their own. It's just too
non-deterministic to support actual multiboot vs dual.

[Bryan J Smith]

Been following this thread for while, and want to interject a couple
of considerations ...

Post by Chris Murphy
What's the problem with just extrapolating from Apple's Disk Utility,
and the Windows Explorer? That's how you partition and format drives
on respective OS's, and neither of them show ESPs, ever. OS X for
over a decade. No one complains about what they can't see!

I cannot speak to OS X, but I think some are giving the NT 6.1
(7/2008) and 6.2 (8/2012) installers way too much credit. In fact,
they will even sometimes create a 2nd ESP and Creator help you if you
have a 2nd drive with another ESP.

Windows' Pre-Installation Environment (WinPE) gets mighty confused at
times, and I've seen a case where it differed with the uEFI firmware
target (not fun to clean up with the partition IDs and all). It
drives me bonkers when I end up with more than one ESP too. [A]

Post by Chris Murphy
How much more research is necessary to know that not showing ESPs
is not a problem?

I've long had a default stance that ...
- Don't overload the user with information
- Offer the option to see more information, plus ...
- Always display that information if it's pertinent before something
negative could happen.

E.g., and I'll let those more familiar with the Anaconda code decide
if this is feasible and useful, or not ...

- When an ESP is detected, show a warning icon (e.g., like red
"exclamation" or maybe a red "stop hand" or something better than
those suggestions)

- Display the extra information if the user clicks that icon

- Display the information when the user attempts to delete the ESP

The extra information would be ...

- Notification that this is an EFI System Partition (ESP) required to
boot most (if not all) operating systems

- List the first 2 levels of the tree in the ESP, which is typically
./EFI/ plus its subdirectories (e.g., fedora, Microsoft, refind,
shell, ubuntu on my triple boot using rEFInd plus EFI shell option).

- A reference to a man page, URL or other information if they wish to
learn more [B]

This would also solve the case where there is more than one ESP
(especially if one is bare). The user could "see" which ESP might be
the one used for the current implementation, or if both are possibly
in use.

Post by Chris Murphy
ESPs have a range in practice. Microsoft OEMs have been creating
them 100MB. Apple did for a while. Now they're in the 200-250MB
realm for most everyone.

Those are Microsoft's OEM recommendations. [799232] [824839]

Originally they were 200MiB in NT6.0 (Vista). They shrunk them to
100MiB with NT6.1+ (7+/2008+), but there can be newer cases in
NT6.2+Update (8.1+SP/2012R2+SP) and NT10 where they are 260MiB because
of support for 4KiB logical. [A]

Post by Chris Murphy
I agree I'm being x86_64 centric.
If we'd hurt embedded users by hiding the ESP in custom, we're also
hurting them with the wrong default in automatic. So their respective
WG or SIG needs to do the necessary customization to make sure the
ESP size default is set for that arch, I'm pretty sure that's possible
now.

As I mentioned, Microsoft expects (although doesn't require) FAT32,
and FAT32 must be a minimum of 260MiB for 4KiB logical. Even though
most of the world is still 512B logical, even for 4KiB physical,
because 4KiB logical booting wasn't supported prior to NT6.2+Update
(8.1+SP/2012R2+SP). So we might want to start considering a default,
"recommended" size, which the user can override.

Post by Chris Murphy
I honestly have no idea what you're talking about. I've only done
several hundred Fedora installations after Windows XP, Vista, 8 and 10
and in every case Fedora did the right thing, except when it didn't
and in every case it didn't it was a legitimate bug. So no the user
doesn't have to know about chainloading and where the Windows
bootloader is located - Windows users don't even know that stuff.

Fedora's Anaconda is definitely the best out there right now, and I've
tested a lot of Windows + Ubuntu, Debian and Debian-based
combinations.

Post by Chris Murphy
You're apparently talking about something that breaks and *then* you
have to know esoterics. I'm saying now with this current behavior and
bug under discussion you need to know esoterics to avoid breaking
Windows, that's how easy it is to break it.

Agreed.

But I still would recommend we take care to avoid the most common
issues, and stick with minimums that accommodate current and any known
future issues.

Post by Chris Murphy
I agree with that. I've asked the Desktop WG if they want to be more
permissive with dual boot and that's a no. There were multiboot (3+)
discussions in QA a while back and that was soundly rejected as
nuttastic, and the user is on their own. It's just too
non-deterministic to support actual multiboot vs dual.

If people are running more than one Linux and one Windows, it gets to
be problematic in general. I mean, even the EFI string used by
efibootmgr gets to be messy in Windows, with Windows overwriting any
existing that matches too.

The user needs to be very experienced with firmware-boot aspects and
it's something we cannot easily accommodate automagically. However,
we can give them information, and more helpful, references to more
information.


-- bjs

DISCLAIMER: I speak for no entities I work on-behalf, am employed or
currently assigned to. I just share my general experiences based on
those engagements and related testing.


o References:

[799232] TechNet Article 799232 - Understanding Disk Partitions (NT6.1
- Windows 7/2008)
- https://technet.microsoft.com/en-us/library/dd799232.aspx

[824839] TechNet Article 824839 - Configure UEFI/GPT-Based Hard Drive
Partitions (NT6.1 - Windows 8/2012)
- https://technet.microsoft.com/en-us/library/hh824839.aspx


o Notes:


[A] This is why I always pre-create at least a 260MiB FAT32 near the
beginning (or to start) the disk, per [799232] [824839].

Again, Windows expects FAT32, and 4KiB logical requires at least
260MiB for FAT32, which will becoming more commonplace, not just 4KiB
physical w/ 512B logical. This is not only for uEFI/GPT, but also for
BIOS/MBR because Windows will use the latter as its "System" drive
under BIOS too. It just solves a lot of WinPE detection-usage issues
in general.

To go one step further, I actually use the first 0.5GiB of the disk for ...
- 1MiB reserved (MBR or GPT header, respectively)
- 383MiB for ESP (EF00h, GPT-only)
- 128MiB for MSFTRES (0C01h, GPT-only)

If there was a way to also put in a note about or reference to the
MSFTRES partition, that would be nice too. But ultimately that's
something that should already be there, if they've installed Windows
first. Despite common rhetoric, the MSFTRES _does_ get used, and
_avoids_ the need for unpartitioned, "hidden" sector usage, like
Microsoft would commonly pull on BIOS/MBR disks.


[B] This is similar to the "header" (follows) I asked to be added by
Anaconda to /etc/fstab in releases over the last half-decade, when I
had customers complaining about switching to UUID and other references
they didn't understand. References to additional info never hurts,
and can fit in a single line (or two).

# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info

[Máirín Duffy]

Post by Chris Murphy
If we'd hurt embedded users by hiding the ESP in custom, we're also
hurting them with the wrong default in automatic. So their respective
WG or SIG needs to do the necessary customization to make sure the ESP
size default is set for that arch, I'm pretty sure that's possible
now.

You just described how we wouldn't actually be hurting them in
automatic. What ISO are they going to be installing with if not one
tailored for embedded? I don't think any of the primary 3 would be
appropriate.

Post by Chris Murphy

Post by Máirín Duffy

Post by Chris Murphy
The consequence of showing them such things is that we're effectively
telling users for the first time in free software OS installer history
they need to understand how Windows boots. They never had to understand
the Windows bootloader esoterics before,

Again, they absolutely had to. Your last sentence there is absolutely
untrue. I have had to manually set up a bootloader to access a Windows
install I unwittingly rendered unbootable via a Linux multiboot installation
before. Multiple times. Multiple distros.

I honestly have no idea what you're talking about. I've only done
several hundred Fedora installations after Windows XP, Vista, 8 and 10
and in every case Fedora did the right thing, except when it didn't
and in every case it didn't it was a legitimate bug. So no the user
doesn't have to know about chainloading and where the Windows
bootloader is located - Windows users don't even know that stuff.

Do you remember this screen?

Loading Image...

We don't have a screen dedicated to bootloader configuration anymore. We
had two - this one, and the advanced one.

Post by Chris Murphy
You're apparently talking about something that breaks and *then* you
have to know esoterics. I'm saying now with this current behavior and
bug under discussion you need to know esoterics to avoid breaking
Windows, that's how easy it is to break it.

Actually, if I didn't have to know esoterics, I wouldn't have broken it
in the first place right? :)

Or did I intentionally break windows with Linux installers back in the
late 90's / early 00's for fun? (No, I don't think so :) )

Post by Chris Murphy

Post by Máirín Duffy

Post by Chris Murphy
but now they do, in order to
avoid trouble in custom partitioning. And that's not a ding on just
Anaconda, all the other distributions do this too by exposing these
bootloader structures to the user. And confusion ensues.

This all affects folks in multi-boot scenarios, which are the majority case
nor really should they be. In 2015 this is an extremely limited user
population we're talking about here: an edge case.

I agree with that. I've asked the Desktop WG if they want to be more
permissive with dual boot and that's a no. There were multiboot (3+)
discussions in QA a while back and that was soundly rejected as
nuttastic, and the user is on their own. It's just too
non-deterministic to support actual multiboot vs dual.

When I say multi-boot though, that is dual-boot inclusive! Would you
argue otherwise, that dual boot is a special multi-boot scenario that is
more common / warranted?

~m