Description of problem:
I'm disallowed from (re)using any read-write snapshot it in Anaconda's Custom partitioning UI. Affects the reuse of a rw snapshot for any purpose, e.g. /home or /boot. For example restoring a "home" from backup using btrfs send-receive.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Complete a default installation
2. Mount the top-level of the btrfs file system, e.g. 'mount /dev/sdXY /mnt'
3. Create a rw snapshot of home, e.g. 'btrfs subvolume snapshot /mnt/home /mnt/home2
4. Reboot and launch the installer, choose Custom partitioning, Btrfs preset, find and click on 'home2'
Upon click on the 'home2' subvolume, on the right side UI I see:
This device cannot be edited directly. You can remove it or select a different device.
I should be able to assign this snapshot to /home mountpoint.
If I create a new subvolume and 'cp -r' the contents from the snapshot to the (new) subvolume, I'm allowed to use it.
It'd be reasonable if blivet were to disallow the use of read-only snapshots, however this is a read-write snapshot.
Created attachment 1718885 [details]
Created attachment 1718886 [details]
Created attachment 1718887 [details]
Advanced-Custom UI allows me to use either a read-write or read-only snaphot.
Proposed as a Blocker for 33-final by Fedora user chrismurphy using the blocker tracking app because:
When using both the installer-native and the blivet-gui-based custom partitioning flow, the installer must be able to: Assign mount points to existing storage volumes. (Expand section further says "this is considered to cover the common operation of re-using an existing /home".)
Strictly speaking the criterion is not violated because the original home subvolume can be assigned to a new installation. Since we're not doing any kind of snapshots nor shipping a way for users to get into this situation via 'btrfs send/receive' restored use home, it's probably reasonable to consider it a 'conditional blocker', i.e. it depends on local configuration to trigger the bug.
(1) few people will be adversely affected during the fedora 33 lifecycle;
(2) relatively easy to work around by cli; such a 'cp -r' is an efficient copy on f33 due to use of reflink copies by default.
Discussed during the 2020-10-05 blocker review meeting: 
The decision to classify this bug as a "RejectedBlocker (Final)" and an "AcceptedFreezeException (Final)" was made as it seems unlikely it will affect many if any people during F33 cycle, given there are likely few existing cases where someone would want to reuse a btrfs /home snapshot. Accepted as a freeze exception issue as there may be *some* cases, and it cannot be fixed with a post-release update.
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.