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): python-blivet-3.3.0-2.fc33 anaconda-33.25.4-1.fc33 How reproducible: Always 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' Actual results: 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. Expected results: I should be able to assign this snapshot to /home mountpoint. Additional info: 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] anaconda.log
Created attachment 1718886 [details] program.log
Created attachment 1718887 [details] storage.log
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: https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria#Custom_partitioning 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. https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F (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: [0] 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. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-10-05/f33-blocker-review.2020-10-05-16.00.txt
python3-blivet-3.4.0-2.fc35.noarch anaconda-35.17-1.fc35.x86_64
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.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.