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:
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
File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1258, in addUdevDevice
File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 2177, in _populate
File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 2111, in populate
File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 372, in reset
File "/usr/lib/python2.7/site-packages/blivet/osinstall.py", line 1128, in storageInitialize
File "/usr/lib64/python2.7/threading.py", line 766, in run
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
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
other involved packages: python-blivet-1.0-1.fc22.noarch, python-libs-2.7.9-5.fc22.x86_64
release: Fedora release 22 (Twenty Two)
Created attachment 1000765 [details]
Created attachment 1000766 [details]
Created attachment 1000767 [details]
Created attachment 1000768 [details]
Created attachment 1000769 [details]
Created attachment 1000770 [details]
Created attachment 1000771 [details]
Created attachment 1000772 [details]
Created attachment 1000773 [details]
Created attachment 1000774 [details]
"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:
Discussed at Fedora Blocker Review Meeting 2015-03-16:
Punt - The QA team would like some more details on reproducing this bug to get more testing before voting on it's blocker status.
(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
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.:
Parent uuid: -
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
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:
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:
This should be resolved in libblockdev, I think.
scratch build with the changes included:
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.
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:
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!
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.