Description of problem: In Manual Partitioning, changing a mount point set to BTRFS device type to LVM causes the mount point to vanish, and an error banner to appear: unrecoverable error. Version-Release number of selected component (if applicable): anaconda 19.24-1 How reproducible: Always. Steps to Reproduce: 1. Installation options, choose "review/modify my disk partitions" and change partition scheme to BTRFS. 2. In manual partitioning, create a new root mount point/partition of any size. 3. Change the device type of the mount point to LVM. Actual results: Mount point vanishes. Unrecoverable error banner appears. Expected results: For the device type to be successfully changed to LVM. Additional info:
Created attachment 743580 [details] anaconda.log
Created attachment 743583 [details] program.log
Created attachment 743584 [details] storage.log
Created attachment 743585 [details] storage.state
Proposing as beta blocker. "When using the custom partitioning flow, the installer must be able to: Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions"
Discussed at 2013-05-06 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-06/f19beta-blocker-review-3.2013-05-06-16.02.log.txt . It doesn't seem to be clear from the report whether this bug is a showstopper or just an inconvenience. Chris, can you clarify the exact impact of this bug when you hit it? Does it prevent you going any further, or can you move on by e.g. removing and re-creating the mount point? We will decide on the status of this bug once we have more information.
Short version: Prevents me from going further, I must quit and relaunch the installer (live), or reboot (dvd/netinst). Long version: Once user makes a partition scheme selection in Installation Options, it's apparently not possible in the present anaconda (unlike 18.x) to get back to Installation. Since I chose BTRFS in Installation Options, that's the default device type for all created mount points (except /boot). When I create a new mount point, it starts out as Btrfs, I change it to LVM, click Apply, and the mount point vanishes with the unrecoverable error described. So it's inconvenient, with a likely non-obvious work around: relaunch/reboot to the installer, and do NOT pick BTRFS in Installation Options as the partition scheme.
So I played around with this a bit. If I set BTRFS on Installation Options, go to custom part, create partitions with the helper link, and then change the / partition from BTRFS to LVM, I get an orange error bar "Device reconfiguration failed. Click for details." If I click on it, I see a dialog which says "invalid raid level descriptor single" and just has a Close button. If I click Close, the partition reverts to BTRFS (and its size shrinks to 1GB, for some reason). However, I can change it from BTRFS to Standard Partition and then to LVM, and that works. I also note that if I set the dropdown on Installation Options to LVM, go into custom part, and create partitions, I can then flip those partitions between LVM and BTRFS indefinitely with no apparent ill effects. So this bug only affects the case where you set the dropdown to BTRFS before going into custom partitioning, and only manifests when you try to change a partition directly from BTRFS to LVM in that case; if you go via Standard Partition as an intermediary, it works okay.
Discussed at 2013-05-08 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-08/f19beta-blocker-review-4.2013-05-08-16.00.log.txt . Rejected as a blocker: clearly a bug, and annoying if you hit the precise path that causes it, but it's quite a specific path (so unlikely to be hit that often) and it is relatively easily workaroundable.
This occurs when switching from btrfs with raid level "single" to lvm.
anaconda-19.27-1.fc19, pykickstart-1.99.31-1.fc19, python-blivet-0.14-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/python-blivet-0.14-1.fc19,pykickstart-1.99.31-1.fc19,anaconda-19.27-1.fc19
Package anaconda-19.27-1.fc19, pykickstart-1.99.31-1.fc19, python-blivet-0.14-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-19.27-1.fc19 pykickstart-1.99.31-1.fc19 python-blivet-0.14-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-8322/python-blivet-0.14-1.fc19,pykickstart-1.99.31-1.fc19,anaconda-19.27-1.fc19 then log in and leave karma (feedback).
Package pykickstart-1.99.31-1.fc19, anaconda-19.28-1.fc19, python-blivet-0.14-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing pykickstart-1.99.31-1.fc19 anaconda-19.28-1.fc19 python-blivet-0.14-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-8322/python-blivet-0.14-1.fc19,pykickstart-1.99.31-1.fc19,anaconda-19.28-1.fc19 then log in and leave karma (feedback).
pykickstart-1.99.31-1.fc19, anaconda-19.28-1.fc19, python-blivet-0.14-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
this was fixed prior to beta release, no need for commonbugs.