Description of problem: Adding encryption to a BTRFS volume, by checking "encrypt" in the volume configuration dialog which also sets size policy and RAID level, fails with a RAID error: "you need at least 1 memberfor RAID level single". Version-Release number of selected component (if applicable): Fedora 21 Alpha Live CD How reproducible: Always Steps to Reproduce: 1. Add a BTRFS volume 2. Open the volume configuration dialog, set size policy to maximum size, and check "encrypt" 3. Close the dialog and click "update" Actual results: RAID error is thrown: "you need at least 1 memberfor RAID level single" Expected results: Encryption should be added to BTRFS volume Additional info: Relevant code path starts at: blivet.devicefactory.PartitionSetFactory.configure, line 1024: `if not member_encrypted and self.encrypted:` * attempts to delete container parents and add encrypted container afterwards * container.parents.remove() fails, error is thrown in blivet.devices.BTRFSVolumeDevice._removeParent: resulting number of devices would be too low for a "single" ersatz raid * the parent that should be deleted in this case is a "non-existant BTRFS partition" Related: https://bugzilla.redhat.com/show_bug.cgi?id=1000031#c3
David, I think this is a result of the change that implementated the hooks for adding/removing devices. It seems like there are cases where we need to inhibit/skip some checks when doing changes (reparenting a device, in this particular case).
That is correct. That check in BTRFSVolumeDevice._removeMember was meant to only apply to existing devices. This exposes the fact that blivet doesn't necessarily ensure that devices with RAID always have an appropriate number of members. That's separate from this, though.
I decided I like us validating member count changes against the current raid level and also validating new raid levels against current member count, so I took a different approach to fixing this. Instead of changing any device classes, I changed the device factory to unset the raid level before configuring the container's member set, thus bypassing any raid-level-specific checks until after we have finished with the member devices.
(In reply to David Lehman from comment #3) > I decided I like us validating member count changes against the current raid > level and also validating new raid levels against current member count, so I > took a different approach to fixing this. Instead of changing any device > classes, I changed the device factory to unset the raid level before > configuring the container's member set, thus bypassing any > raid-level-specific checks until after we have finished with the member > devices. Sounds good to me.
anaconda-21.48.10-1.fc21, pykickstart-1.99.63-2.fc21, python-blivet-0.61.5-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/pykickstart-1.99.63-2.fc21,python-blivet-0.61.5-1.fc21,anaconda-21.48.10-1.fc21
Package anaconda-21.48.10-1.fc21, pykickstart-1.99.63-2.fc21, python-blivet-0.61.5-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-21.48.10-1.fc21 pykickstart-1.99.63-2.fc21 python-blivet-0.61.5-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-12944/pykickstart-1.99.63-2.fc21,python-blivet-0.61.5-1.fc21,anaconda-21.48.10-1.fc21 then log in and leave karma (feedback).
anaconda-21.48.10-1.fc21, pykickstart-1.99.63-2.fc21, python-blivet-0.61.5-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.