Description of problem: I have several btrfs volumes, one with lots of docker snapshots. Anaconda crashed while trying to enumerate these volumes. Version-Release number of selected component: anaconda-core-22.20.2-1.fc22.x86_64 The following was filed automatically by anaconda: anaconda 22.20.2-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1736, in handleBTRFSFormat raise DeviceTreeError("could not find parent for subvol") File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1883, in handleUdevDeviceFormat self.handleBTRFSFormat(info, device) File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1258, in addUdevDevice self.handleUdevDeviceFormat(info, device) File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 2177, in _populate self.addUdevDevice(dev) File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 2111, in populate self._populate() File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 372, in reset self.devicetree.populate(cleanupOnly=cleanupOnly) File "/usr/lib/python2.7/site-packages/blivet/osinstall.py", line 1128, in storageInitialize storage.reset() File "/usr/lib64/python2.7/threading.py", line 766, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 238, in run threading.Thread.run(self, *args, **kwargs) DeviceTreeError: could not find parent for subvol Additional info: cmdline: /usr/bin/python2 /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-22_A-3 rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 nomodeset executable: /sbin/anaconda hashmarkername: anaconda kernel: 4.0.0-0.rc1.git0.1.fc22.x86_64 other involved packages: python-blivet-1.0-1.fc22.noarch, python-libs-2.7.9-5.fc22.x86_64 product: Fedora" release: Fedora release 22 (Twenty Two) type: anaconda version: Fedora
Created attachment 1000765 [details] File: anaconda-tb
Created attachment 1000766 [details] File: anaconda.log
Created attachment 1000767 [details] File: environ
Created attachment 1000768 [details] File: journalctl
Created attachment 1000769 [details] File: lsblk_output
Created attachment 1000770 [details] File: nmcli_dev_list
Created attachment 1000771 [details] File: os_info
Created attachment 1000772 [details] File: program.log
Created attachment 1000773 [details] File: storage.log
Created attachment 1000774 [details] File: ifcfg.log
"DeviceTreeError: could not find parent for subvol" What parent does this refer to? Subvols, including snapshots, aren't guaranteed to have a parent.
Proposed as a Blocker for 22-beta by Fedora user chrismurphy using the blocker tracking app because: When using the custom partitioning flow, the installer must be able to: Correctly interpret ... btrfs volumes.
There's a slightly more detailed version of the error logged to storage.log: 21:35:55,899 ERR blivet: failed to find parent (328) for subvol home/ravi the code is: https://github.com/dwlehman/blivet/blob/f22-branch/blivet/devicetree.py#L1715-L1736
Discussed at Fedora Blocker Review Meeting 2015-03-16[0]: Punt - The QA team would like some more details on reproducing this bug to get more testing before voting on it's blocker status. [0]: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-03-16/f22-blocker-review.2015-03-16-16.01.log.txt
(In reply to Adam Williamson (Red Hat) from comment #13) Entirely plausible the "parent" was deleted, possibly a long time ago. I'm not following the code quickly or well enough to understand the purpose of this distinction. 1742 device_class = BTRFSSnapShotDevice 1743 else: 1744 device_class = BTRFSSubVolumeDevice Btrfs doesn't have such a distinction. A snapshot is a subvolume. The user space tools have a superficial distinction due to metadata it tracks, e.g.: Name: root uuid: 9e1bc058-24f9-164c-b71e-b4f8da3e2c06 Parent uuid: - --- Name: rootsnap uuid: 593cfa3b-7174-bd4a-ab58-bfbec6e97d82 Parent uuid: 9e1bc058-24f9-164c-b71e-b4f8da3e2c06 But I can delete either of these without affecting the other. So it's legit for me to delete the first one, leaving the 2nd one with a parent uuid that no longer exists.
If you need any specific info from me, please let me know so I can get it for you. At a minimum, it should let the install proceed and let the user select which ever subvolume/drives to install to so he can proceed with the installation. Complete crash should not be acceptable. There is no fallback at all right now.
(In reply to Ravi Terala from comment #16) What do you get for: # btrfs subvolume list -apt /mnt If ID 328 isn't listed, can you give an idea what happened? Was it deleted?
Running... btrfs subvol list -p /tmp/btrfs-tmp.106uMZp8o stdout: ID 257 gen 26934 parent 328 top level 328 path home/ravi ID 258 gen 25435 parent 328 top level 328 path home/aniketh ID 327 gen 26852 parent 5 top level 5 path docker ID 328 gen 23724 parent 5 top level 5 path home <lots of snapshots omitted> So the problem is that the output is sorted by id while the dependencies are determined by path/name. Blivet either needs to sort the subvols by path before trying to add them or expand the code that adds them to allow on-demand addition like we do for lvm. Or we could use blivet.tsort to determine an appropriate order.
I think this should fix the issue: http://paste.fedoraproject.org/199765/67100321/
(In reply to Vratislav Podzimek from comment #19) > I think this should fix the issue: > http://paste.fedoraproject.org/199765/67100321/ To easily test the change, could somebody please try running: # btrfs subvol list -p --sort=path /tmp/btrfs-tmp.106uMZp8o on the affected system and post the result here?
Created attachment 1004261 [details] Btrfs subvol list btrfs sub volume list as requested.
(In reply to Ravi Terala from comment #21) > Created attachment 1004261 [details] > Btrfs subvol list > > btrfs sub volume list as requested. Hmm, this is what we need: > ID 327 gen 28249 parent 5 top level 5 path docker > ID 328 gen 26961 parent 5 top level 5 path home > ID 258 gen 25435 parent 328 top level 328 path home/aniketh > ID 257 gen 28257 parent 328 top level 328 path home/ravi But all the btrfs/subvolumes/* subvolumes (snapshots, I guess?) whose path doesn't start with the parent's path ("docker") would cause the same issues as the "home/ravi" in this first case. So this needs a more complex solution.
Discussed at 2015-03-23 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-03-23/f22-blocker-review.2015-03-23-16.02.log.txt . Accepted as a Beta blocker per criterion cited in #c12.
A fix tested on data extracted from this bug report: https://github.com/rhinstaller/libblockdev/pull/6
This should be resolved in libblockdev, I think.
scratch build with the changes included: http://koji.fedoraproject.org/koji/taskinfo?taskID=9312774 Ravi, could you please try running the installation with the RPMs from the above build installed?
I booted with with USB key last time. Can you provide me instructions on how to use these bits?
(In reply to Ravi Terala from comment #27) > I booted with with USB key last time. Can you provide me instructions on how > to use these bits? Unfortunately, neither 'bodhi -D 9312774' nor 'koji download-build 9312774' work in F22, so here's the stupid thing you'd have to do to update libblockdev to the should-be-fixed version: $ sudo dnf update https://kojipkgs.fedoraproject.org//work/tasks/2774/9312774/libblockdev-0.7-1_rhbz_1201120.fc22.x86_64.rpm https://kojipkgs.fedoraproject.org//work/tasks/2774/9312774/libblockdev-btrfs-0.7-1_rhbz_1201120.fc22.x86_64.rpm https://kojipkgs.fedoraproject.org//work/tasks/2774/9312774/libblockdev-crypto-0.7-1_rhbz_1201120.fc22.x86_64.rpm https://kojipkgs.fedoraproject.org//work/tasks/2774/9312774/libblockdev-dm-0.7-1_rhbz_1201120.fc22.x86_64.rpm https://kojipkgs.fedoraproject.org//work/tasks/2774/9312774/libblockdev-loop-0.7-1_rhbz_1201120.fc22.x86_64.rpm https://kojipkgs.fedoraproject.org//work/tasks/2774/9312774/libblockdev-lvm-0.7-1_rhbz_1201120.fc22.x86_64.rpm https://kojipkgs.fedoraproject.org//work/tasks/2774/9312774/libblockdev-mdraid-0.7-1_rhbz_1201120.fc22.x86_64.rpm https://kojipkgs.fedoraproject.org//work/tasks/2774/9312774/libblockdev-mpath-0.7-1_rhbz_1201120.fc22.x86_64.rpm https://kojipkgs.fedoraproject.org//work/tasks/2774/9312774/libblockdev-plugins-all-0.7-1_rhbz_1201120.fc22.x86_64.rpm https://kojipkgs.fedoraproject.org//work/tasks/2774/9312774/libblockdev-swap-0.7-1_rhbz_1201120.fc22.x86_64.rpm https://kojipkgs.fedoraproject.org//work/tasks/2774/9312774/libblockdev-utils-0.7-1_rhbz_1201120.fc22.x86_64.rpm
There's a 'koji-download-scratch' command which, for reasons that i'm sure made sense at the time, lives in fedora-review... Ravi, if the bug is reproducible from a live image, all you need to do is boot the live image, update the libblockdev packages from the scratch build, then run the install. It's possible to update and install packages in a live image, at least until you run out of RAM. If it's only reproducible from a non-live installer image, it's a bit trickier, we'll have to build you a custom one with the new libblockdev included. If you need that, let me know, and I'll do it. Thanks!
anaconda-22.20.7-1.fc22, libblockdev-0.8-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/FEDORA-2015-4952/libblockdev-0.8-1.fc22,anaconda-22.20.7-1.fc22
Package anaconda-22.20.7-1.fc22, libblockdev-0.8-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-22.20.7-1.fc22 libblockdev-0.8-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-4952/libblockdev-0.8-1.fc22,anaconda-22.20.7-1.fc22 then log in and leave karma (feedback).
Ravi, the fix for this should be in Beta TC6; can you please test and let us know? Thanks! https://dl.fedoraproject.org/pub/alt/stage/22_Beta_TC6/
I've updated the libblockdev and anaconda as suggested and ran the live installer. The bug is now fixed and it takes me to the selection place correctly.
Thanks a lot for testing! Marking as VERIFIED.
anaconda-22.20.7-1.fc22, libblockdev-0.8-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.