What were you trying to do that didn't work?

Installation of RHEL-9.6 on a machine with existing partitioning with a PV on an unpartitioned disk failed with the following traceback:

ERROR:anaconda.modules.common.task.task:Thread AnaTaskThread-CreateStorageLayoutTask-1 has failed: Traceback (most recent call last):
  File "/usr/lib64/python3.9/site-packages/gi/overrides/BlockDev.py", line 1092, in wrapped
    ret = orig_obj(*args, **kwargs)
  File "/usr/lib64/python3.9/site-packages/gi/overrides/BlockDev.py", line 618, in lvm_lvdeactivate
    return _lvm_lvdeactivate(vg_name, lv_name, extra)
gi.repository.GLib.GError: g-bd-utils-exec-error-quark: Process reported exit code 5:   Device not found for /dev/vdb1.
  Device not found for /dev/vdf1.
  Device not found for /dev/vde1.
  Device not found for /dev/vda2.
  Device not found for /dev/vdc1.
  Device not found for /dev/vdd1.
  Logical volume test/testlv is used by another device.
 (0)

I'm not sure if I understood well partitioning actions were planned and put in place in storage.log, but my understanding is that Blivet properly detected the PV/VG/LV on a second disk (/dev/vdb), but tried to activate the LV with a constraint using improper list of devices (/dev/vda2, ...), but not /dev/vdb. Other aspect is that - unless I'm missing something important - that Blivet tried to activate the LV at a time where it was destroying some other parts of the existing partitioning and the LV/VG/PV had been already planned to be destroyed as well.

What is the impact of this issue to you?

One of our tests is potentially (see below) failing and such a setup could result in minor issues for the users (it would be necessary to clear the partitioning manually first).

Please provide the package NVR for which the bug is seen:

anaconda-34.25.5.11-1.el9

How reproducible is this bug?:

I wasn't able to reproduce it yet - even though I'd expect it should be easily reproducible by using the same existing partitioning when running a new installation. I've created this bug for tracking purposes should we or someone else hit it as well, hopefully with particular steps on how to reproduce it.

Steps to reproduce

The reproducer isn't known yet, but the bug happened during run of our automated test that does the following steps:

Prepare a machine with at least two disks.

1. (setup) Install system on one of the disks.
2. (setup) Create LVM partitioning on the second disk using the following steps:
   1. wipefs -a /dev/$disk2
   2. pvcreate -ff -y $disk2
   3. vgcreate test $disk2
   4. lvcreate -l 100%FREE --permission r --setactivationskip y -n testlv test
3. Run a new RHEL-9.6 installation, select all of the available disk devices to be used for partitioning and let Anaconda do the partitioning automatically.

Expected results

The old partitioning is removed and a default new one created, system installation is successful.

Actual results

Traceback due to an error related to improper LV activation in the existing partitioning.