Version-Release number of selected component: anaconda-20.22-1.fc20.x86_64 The following was filed automatically by anaconda: anaconda 20.22-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 295, in _removeDevice raise ValueError("Cannot remove non-leaf device '%s'" % dev.name) File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 351, in registerAction self._removeDevice(action.device) File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 1215, in destroyDevice self.devicetree.registerAction(action) File "/tmp/updates/pyanaconda/ui/gui/spokes/custom.py", line 2067, in _destroy_device self.__storage.destroyDevice(device) File "/tmp/updates/pyanaconda/ui/gui/spokes/custom.py", line 2189, in on_remove_clicked self._destroy_device(dev) ValueError: Cannot remove non-leaf device 'btrfs.14' Additional info: cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8 cmdline_file: BOOT_IMAGE=/syslinux/vmlinuz0 root=live:UUID=A2E2-CEB0 rw rd.live.image overlay=UUID=A2E2-CEB0 noop updates=http://bcl.fedorapeople.org/updates/1010495.img executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.11.3-301.fc20.x86_64 other involved packages: python-blivet-0.22-1.fc20.noarch product: Fedora release: Fedora release 20 (Heisenbug) type: anaconda version: 20 Potential duplicate: bug 888450
Created attachment 809636 [details] File: anaconda-tb
Created attachment 809637 [details] File: anaconda.log
Created attachment 809638 [details] File: environ
Created attachment 809639 [details] File: journalctl
Created attachment 809640 [details] File: lsblk_output
Created attachment 809641 [details] File: nmcli_dev_list
Created attachment 809642 [details] File: os_info
Created attachment 809643 [details] File: program.log
Created attachment 809644 [details] File: storage.log
Created attachment 809645 [details] File: ifcfg.log
Might be related to bug 1016925. Is reproducible.
Created attachment 809646 [details] 2nd anaconda-tb
Created attachment 809647 [details] storage.state
Reproduce steps: 1. Existing btrfs volume on conventional (not thinp) LVM2 LV. The btrfs volume contains only two empty subvolumes under the default subvolume (subvolid=0/5), which is the one thing that's the same as bug 1016925. 2. Guided partitioning, partition scheme standard partitioning, click on the custom partitioning button. 3. In Manual partitioning, click on the reveal triangle for existing installation Fedora 20. /boot is already highlighted, I click the - (minus) button to delete it. In the resulting dialog, I check the option to delete all other partitions related to this one. ~30 second pause. Crash.
Reproduces with anaconda 20.12-1 from alphaTC5, through 20.22-1. Media passes checksums. Happens with or without http://bcl.fedorapeople.org/updates/1010495.img for making installs work on Macs. Proposing as F20 beta blocker: "When using the custom partitioning flow, the installer must be able to remove existing storage volumes, (and reject or disallow invalid disk and volume configurations without crashing.)"
The main volume (volid 0) is in the fstab and there are subvolumes, so there is a non-leaf device in the Fedora 20 page. Not needed in this case (the "remove all" checkbutton was activated), but we may need to add a dialog to warn when removing a volume that contains subvolumes. For this case, we can add some special-case code to handle it quietly in _destroy_device since the UI layer above is where the prompt/warning would occur.
Discussed this in 2013-10-09 Blocker Review Meeting [1]. Voted as a AcceptedBlocker as it violates the following F20 beta release criterion, assuming that the disk layout in question is not considered valid: "When using the custom partitioning flow, the installer must be able to ... Reject or disallow invalid disk and volume configurations without crashing." [2] [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-09/ [2] https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Guided_partitioning
Created attachment 810193 [details] screencast, how to trigger crash
This bug is reproducible without LVM. Crash occurs whenever the installation being deleted contains an /etc/fstab entry for a btrfs volume that does not use subvol= mount option. Because the user can specify a default subvolume which is not the top level 5 subvolume (the default subvolume with a new btrfs volume), there's no way in the current anaconda UI to infer that the user intends for the entire btrfs volume to be deleted just because the fstab entry lacks a subvol= mount option.
There are two separate issues at play here: 1. blivet does not have any concept of the default subvolume 2. anaconda does not account for the possibility that the main volume might have a mountpoint (*). Closely related is the fact that blivet does not understand that subvolumes with paths inside another subvolume are nested within the containing directory's subvolume as opposed to being at the same level. Item 1 is easily resolved. I have an untested patch that should give blivet the ability to determine the default subvolume and resolve device specs that do not explicitly identify a subvolume correctly. Item 2 is slightly more complicated. Even a minimally intrusive solution would require a new dialog (anaconda) to warn users when removing a volume that contains subvolumes in addition to backend code (blivet) to identify the subvolume hierarchy and handle it correctly. * btrfs violates the rule followed by all other types of storage up to this point (**) that only leaf devices may contain mountable filesystems or swap space ** bcache, for which blivet support is in development, also violates the only-leaves-are-mountable rule
I'm uncertain if blivet needs to be default subvolume aware at all: I confirmed with a btrfs developer that default subvolume is only meant to affect mount behavior absent a subvol= or subvolid= option. The intent is subvol= is always an absolute path whether prefaced with /. Therefore there should be no such thing as subvol= being interpreted as relative to the default subvolume. Also kernels+btrfsprogs in the last ~year, regardless of default subvolume or mount subvol= option used, "btrfs subvol list <anymountpoint>" will list all subvolumes, not just the ones below the mount point. So the existence of all subvolumes on a volume should be discoverable. And re: item2 yes this is difficult, and I think before requiring a premature fix under auspices of criteria adherence, that it's better to document the issue and discuss how this should behave. I think UI/UX wise at least, it relates to the RFE bug 1015657, and also LVM Thin Provisioning pools which are something in between a VG and LV and likewise lacks UI.
Discussed in 2013-10-30 Blocker Review Meeting [1]. Voted as a RejectedBlocker. After receiving more details about this bug, we consider this to be a corner case situation that should not block Beta. We will document this in CommonBugs. Please repropose for Final if you think it should block it. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-30/
Are bug 968149, and bug 888450 dups? Or related? For commonbugs, the gist is: If you have an existing Fedora install with an fstab containing a btrfs entry that lacks subvol= or subvolid= mount option, the installer will crash if you choose to delete all subvolumes. Available work arounds are: don't delete all subvolumes in the installer (do that before or after installing from cli); or ensure fstab btrfs entries explicitly mount a subvolume with subvol= or subvolid= before running the installer.
Updates image available for testing (against 20-TC2): http://dlehman.fedorapeople.org/updates/updates-1121.0.img This should make blivet's representation of the btrfs volume hierarchy accurate and add some warning text when removing a btrfs volume that contains subvolumes in anaconda.
python-blivet-0.23.6-1.fc20, anaconda-20.25.11-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/FEDORA-2013-21928/python-blivet-0.23.6-1.fc20,anaconda-20.25.11-1.fc20
Package python-blivet-0.23.6-1.fc20, anaconda-20.25.11-1.fc20, pykickstart-1.99.48-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing python-blivet-0.23.6-1.fc20 anaconda-20.25.11-1.fc20 pykickstart-1.99.48-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-21928/pykickstart-1.99.48-1.fc20,python-blivet-0.23.6-1.fc20,anaconda-20.25.11-1.fc20 then log in and leave karma (feedback).
I tried to delete previous linux destribution cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8 cmdline_file: initrd=initrd0.img root=live:CDLABEL=Fedora-Live-Desktop-x86_64-20-Al rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=vmlinuz0 hashmarkername: anaconda kernel: 3.11.0-300.fc20.x86_64 other involved packages: python-blivet-0.20-1.fc20.noarch package: anaconda-20.18-1.fc20.x86_64 packaging.log: product: Fedora reason: ValueError: Cannot remove non-leaf device 'btrfs.38' release: Fedora release 20 (Heisenbug) version: 20
python-blivet-0.23.7-1.fc20, anaconda-20.25.12-1.fc20, pykickstart-1.99.48-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Fixed in final TC4.