Bug 2222960

TL;DR: This is the designed behavior of the CheckVdo LEAPP actor.

Details:
The change in going from pre-RHEL9 to RHEL9 involves the necessary conversion of existing VDOs from being managed via VDO's python-based management to LVM-based management. The CheckVdo LEAPP actor takes an explicitly conservative approach (to prevent loss of access to data) in determining whether or not a block device is one of:

1. non-VDO
2. pre-conversion VDO
3. completed post-conversion VDO
4. incomplete post-conversion VDO (LVM configuration was not completed; e.g., due to a system crash)

A post-conversion VDO is not identified as 'vdo' but as 'lvm'.
To correctly categorize such devices CheckVdo requires a utility that understands the post-conversion VDO format.  The VDO-provided vdoprepareforlvm utility is used to perform this check.

The lack of vdoprepareforlvm (or an unexpected error condition) adds the additional categorization of

5. undetermined

Note that undetermined could be the result of the user (however erroneously) leaving the system without the software to perform the necessary checks.
In keeping with CheckVdo's conservative approach the categorization as undetermined (in addition to pre-conversion VDO and incomplete post-conversion VDO) results in CheckVdo inhibiting upgrade.

As CheckVdo errs on the side of caution if the user knows this to be the case they may specify an override to CheckVdo to allow the upgrade to proceed.

---
From the CheckVdo description:

    Check if VDO devices need to be migrated to lvm management.

    `Background`
    ============
    In RHEL 9.0 the independent VDO management software, `vdo manager`, is
    superseded by LVM management.  Existing VDOs must be converted to LVM-based
    management *before* upgrading to RHEL 9.0.

    The `CheckVdo` actor provides a pre-upgrade check for VDO devices that have
    not been converted and, if any are found, produces an inhibitory report
    during upgrade check phase.   If none are found `CheckVdo` does not produce
    a report concerning such VDO devices.

    As there currently exists the theoretical possibility that a VDO device may
    not complete its conversion to LVM-based management (e.g., via a poorly
    timed system crash during the conversion) `CheckVdo` also provides a
    pre-upgrade check for VDO devices in this state.  If any are found
    `CheckVdo` produces an inhibitory report during upgrade check phase.  If
    none are found `CheckVdo` does not produce a report concerning such VDO
    devices.

    If the VdoConversionInfo model indicates unexpected errors occurred during
    scanning CheckVdo will produce appropriate inhibitory reports.

    If the VdoConversionInfo model indicates conditions exist where VDO devices
    could exist but the necessary software to check was not installed on the
    system CheckVdo will present a dialog to the user. This dialog will ask the
    user to either install the required software if the user knows or is unsure
    that VDO devices exist or to approve the continuation of the upgrade if the
    user is certain that either there are no VDO devices present or that all
    VDO devices have been successfully converted.

    To maximize safety CheckVdo operates against all block devices which
    match the criteria for potential VDO devices.  Given the dynamic nature
    of device presence within a system some devices which may have been present
    during leapp discovery may not be present when CheckVdo runs.  As CheckVdo
    defaults to producing inhibitory reports if a device cannot be checked
    (for any reason) this dynamism may be problematic.  To prevent CheckVdo
    producing an inhibitory report for devices which are dynamically no longer
    present within the system the user may answer the previously mentioned
    dialog in the affirmative when the user knows that all VDO devices have
    been converted.  This will circumvent checks of block devices.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.