Description of problem: Open Anaconda installer in Live CD and wait a bit. I have an existing Fedora installation on my system with several BTRFS snapshots. Version-Release number of selected component: anaconda-core-38.23.4-2.fc38.x86_64 The following was filed automatically by anaconda: anaconda 38.23.4 exception report Traceback (most recent call first): File "/usr/lib/python3.11/site-packages/dasbus/client/handler.py", line 509, in _handle_method_error raise exception from None File "/usr/lib/python3.11/site-packages/dasbus/client/handler.py", line 483, in _get_method_reply return self._handle_method_error(error) File "/usr/lib/python3.11/site-packages/dasbus/client/handler.py", line 450, in _call_method return self._get_method_reply( File "/usr/lib64/python3.11/site-packages/pyanaconda/modules/common/task/__init__.py", line 46, in sync_run_task task_proxy.Finish() File "/usr/lib64/python3.11/site-packages/pyanaconda/ui/lib/storage.py", line 97, in reset_storage sync_run_task(task_proxy) File "/usr/lib64/python3.11/threading.py", line 975, in run self._target(*self._args, **self._kwargs) File "/usr/lib64/python3.11/site-packages/pyanaconda/threading.py", line 275, in run threading.Thread.run(self) pyanaconda.modules.common.errors.general.AnacondaError: could not find parent for subvol Additional info: .~lock.lsblk_output#: ,root,localhost-live,30.05.2023 01:05,file:///tmp/.config/libreoffice/4; cmdline: /usr/bin/python3 /sbin/anaconda --liveinst --graphical executable: /sbin/anaconda hashmarkername: anaconda product: Fedora package: anaconda-core-38.23.4-2.fc38.x86_64 reason: pyanaconda.modules.common.errors.general.AnacondaError: could not find parent for subvol kernel: 6.2.9-300.fc38.x86_64 type: anaconda release: Fedora release 38 (Thirty Eight) cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-KDE-Live-38-1-6 rd.live.image rd.live.check quiet addons: com_redhat_kdump version: 38 other involved packages: python3-libs-3.11.2-1.fc38.x86_64, python3-dasbus-1.7-2.fc38.noarch
Created attachment 1967790 [details] File: anaconda-tb
Created attachment 1967791 [details] File: backtrace
Created attachment 1967792 [details] File: sdb4-btrfs-subvols
Created attachment 1967793 [details] File: os_info
Created attachment 1967794 [details] File: environ
Created attachment 1967795 [details] File: journalctl
Created attachment 1967796 [details] File: description
Created attachment 1967797 [details] File: storage.log
Created attachment 1967798 [details] File: program.log
Created attachment 1967799 [details] File: nmcli_dev_list
Open Anaconda installer in Live CD and wait a bit. I have an existing Fedora installation on my system with several BTRFS snapshots. .~lock.lsblk_output#: ,root,localhost-live,30.05.2023 01:05,file:///tmp/.config/libreoffice/4; cmdline: /usr/bin/python3 /sbin/anaconda --liveinst --graphical hashmarkername: anaconda product: Fedora package: anaconda-core-38.23.4-2.fc38.x86_64 reason: pyanaconda.modules.common.errors.general.AnacondaError: could not find parent for subvol kernel: 6.2.9-300.fc38.x86_64 release: Fedora release 38 (Thirty Eight) cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-KDE-Live-38-1-6 rd.live.image rd.live.check quiet addons: com_redhat_kdump version: 38 other involved packages: python3-libs-3.11.2-1.fc38.x86_64, python3-dasbus-1.7-2.fc38.noarch
From storage.log >ERROR:blivet:failed to find parent (287) for subvol snapshots/4/snapshot/.backup/btrfs However: >INFO:program:Running [7] btrfs subvol get-default /tmp/btrfs-tmp.14450bi6jkc ... >INFO:program:stdout[7]: ID 287 gen 112159 top level 283 path snapshots/4/snapshot So it is present. And the parent of this subvolume is also present: >ID 283 gen 112039 parent 5 top level 5 path snapshots So I'm not sure why this is happening... >INFO:program:Running [7] btrfs subvol get-default /tmp/btrfs-tmp.14450bi6jkc ... >INFO:program:stdout[7]: ID 287 gen 112159 top level 283 path snapshots/4/snapshot The default subvolume is ID 287, aka snapshots/4/snapshot, which happens to be the one anaconda claims it can't find. Well in any case, anaconda is confused and then it crashes, so it's definitely a bug. Maybe it's possible to work around this problem by changing the default subvolume? Try mount -o subvolid=5 /dev/sdb4 /mnt btrfs subvolume set-default 5 /mnt And then retry the installer? sudo btrfs subvolume set-default 5 /mnt
Thanks Chris. I tried what you suggested in Konsole before running Anaconda: mount -o subvolid=5 /dev/sdb4 /mnt btrfs subvolume set-default 5 /mnt And then ran Anaconda by clicking the icon in the live image. But I got the same error. Is it possible that my SSD itself is damaged and/or the BTRFS metadata itself is corrupted? Someone in IRC suggested using blkdiscard(8) to simply drop everything on the disk and start over. I have the backups that I need, so is that the next available option? Happy to try additional debugging steps as well, provide additional info, etc. By the way, the window showing that Anaconda has crashed also appears to be buggy. The window cannot be interacted with in any way. The "More info" expandable caret thing is not clickable, nor are the "Report Bug" or "Quit" buttons (no idea how I managed to report this bug the first time!), and the window is only draggable when holding Super. Is there already a bug report to track this issue, or should I create a 2nd bug here?
I ended up wiping it all and installing from scratch. I hate to put so much wear on my SSD but I didn't see another option. Hopefully there's some information I can provide that would help here.
The wear on the SSD due to reinstalling is pretty negligible on a modern SSD. I just think the installer is confused for some reason I can't figure out. And then it can't handle its own confusion gracefully so it crashes. Another work around would have been to manually delete the snapshots, thereby avoiding whatever resulted in the confusion in the first place.
I believe anaconda can't handle btrfs snapshots. Vojto, do you know more?
Moving to blivet for further investigation. Anaconda might not support working with btrfs snapshots in the UI, but it definitely shouldn't crash. The crash itself comes from blivet, so we need to fix it there. We have some long standing issues to make blivet more stable in situation where we encounter unknown/unsupported setups and this is a nice example of situation where we should ignore the "missing" parent device instead of crashing like this.
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.