Bug 1040148

Created attachment 834910 [details]
anaconda.log

Created attachment 834911 [details]
anaconda-tb

Created attachment 834912 [details]
program.log

Created attachment 834913 [details]
syslog

Created attachment 834914 [details]
X.log

anaconda 20.25.14-1 exception report
Traceback (most recent call first):
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1610, in handleBTRFSFormat
    raise DeviceTreeError("could not find parent for subvol")
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1735, in handleUdevDeviceFormat
    self.handleBTRFSFormat(info, device)
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1075, in addUdevDevice
    self.handleUdevDeviceFormat(info, device)
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1962, in _populate
    self.addUdevDevice(dev)
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1906, in populate
    self._populate()
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 416, in reset
    self.devicetree.populate(cleanupOnly=cleanupOnly)
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 142, in storageInitialize
    storage.reset()
  File "/usr/lib64/python2.7/threading.py", line 764, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 192, in run
    threading.Thread.run(self, *args, **kwargs)
DeviceTreeError: could not find parent for subvol

Just to clarify:  This is just the "straight" TC5 DVD; no updates disk or or other modifications.

Yes, this install has rootfs on btrfs but /boot is on a regular partition with ext4.

Same configuration with F20-Beta DVD boots up fine.

Same hardware, same TC5 DVD:

I did a kickstart text install which worked fine.  This is basically a network install and actual install software comes from repositories and not the DVD.

OK, I believe I may have found what is causing the strange errors.

It looks like anaconda/blivet is scanning of of the partitions and subvolumes on disks it is OK'ed for.  But, why is it looked for rootfs's and then analyzing the /etc/fstab to verify that everything in it exists.  Is this something new ... I would guess it is because things did work but do not now.

This systems have multiple installs on them.  Some can boot and some cannot boot because they are no longer valid.

Just because I know what is wrong now and can correct for it, I believe that this new process is not doing the right thing.  In other words, this is a bug.

07:50:12,297 INFO program: Running... mount -t btrfs -o subvolid=5 /dev/sdb1 /tmp/btrfs-tmp.17qssMpi
07:50:12,366 DEBUG program: Return code: 0
07:50:12,370 INFO program: Running... btrfs subvol list -p /tmp/btrfs-tmp.17qssMpi
07:50:12,391 INFO program: ID 290 gen 61112 parent 0 top level 0 path DELETED
07:50:12,392 INFO program: ID 307 gen 139672 parent 5 top level 5 path root3
07:50:12,393 DEBUG program: Return code: 0


Did you create the DELETED subvol yourself or is that some btrfs artifact? It has an invalid parent volume id.

I have no idea where DLETED came from.  It is gone now.

However, I believe I have trace the problem to the recent blivet commit 29448424d5eb638ab1841b07a6a32d3cb085fa30

I guess blivet has been scanning/verifying all /etc/fstab files (and I notice /etc/blkid/blkid.tab) but this new update catches the problem.

This has nothing to do with /etc/fstab or blkid.tab or anything along those lines.

I do not know where the DELETED subvol came from, but it had an invalid parent volume id and therefore it was impossible to proceed with installation. I don't see a bug here. It is not reasonable to expect installation to proceed when the system's storage is in a state that prevents the installer from ascertaining the initial configuration.

I believe I know where DELETED came from and you are correct in closing this as NOT-A-BUG.  This was something created by BTRFS itself.  On one of my failed test attempts, I decided to delete the rootfs' subvol I was creating so I could try again.  The system crashed before completing the umount.

That said, I believe that there is a problem cause by the above mentioned commit.  However, I also believe that the commit should not be backed off ... only corrected and certainly documented as to what can happen.  I will create a test case and open a new report.

The two cases I saw were:

1. The /home subvol had been moved from one BTRFS volume to another (different) BTRFS volume but a second installed system had an fstab which still pointed to the original BTRFS volume. I re-formatted/rebuilt that whole BTRFS volume (new UUID), blivet could not find the parent for the /home subvol.

2. Installed on a pair of /boot on /dev/sda6 (ext4) + rootfs on a logical volume "root1".  Then added more SSDs and install a system there using the /dev/sda6 for /boot but rootfs is not on the new SSDs.  The old "root1" logical volume still existed but when the /etc/fstab was checked, it could not find anything with that UUID.

Well, much to my chagrin there does not appear to be a problem!

In the first case, it does appear that the basic problem was the strange "DELETED" subvolume.  With it gone, there are now no problems installing on that system.

In the second case, the problem was an error in the kickstart file which was not apparent when kickstart installing with the GUI interface.  Switching to a text install immediately produced a meaningful error message citing the line in the kickstart file which was the problem.  I wonder if there is a way to get such a message in the gui mode.