The basic idea of using system.devices on the host is the right idea; this is one of the specific cases that we created the devices file to address (in RHV at the time.)  The hard part is the installation/initialization issues, because everything in that area is so customized these days, it's not just anaconda these days.  It's likely that customized installation methods will also need custom ways to handle the devices file.

The basic logic, as you've already seen, is:
- No system.devices disables the feature, and causes the machine to fall back to using the lvm.conf filter.  
- Existing but empty system.devices enables the feature, and causes the machine to see no PVs.
- pvcreate will create a new system.devices file only if there are no other PVs seen on the machine.
- lvmdevices --adddev and vgimportdevices will always create a new system.devices file.

This logic allows us to enable the devices file feature by default in RHEL9, while also allowing upgrades from RHEL8 without any disruption for users.  Existing lvm.conf filters users had configured in RHEL8 will continue to work after upgrading to RHEL9.  A user who wants to enable the devices file after upgrading can just run vgimportdevices -a.

For anaconda, it was simpler for them to keep the devices file feature off during installation, which meant they could just keep all their existing lvm usage unchanged.  At the end they just added vgimportdevices -a to create a new system.devices from the PVs they'd created.

The suggestion to create a new, empty system.devices file from the rpm install sounds reasonable, but I worry about it breaking other cases.  What if a user uninstalls and reinstalls the lvm rpm?  Wouldn't that break machines that are depending on no system.devices to disable the feature?  I have very little knowledge about the creative ways that rpms are used, and what expectations exist.  Maybe someone with more expertise can tell us what's safe to assume in an rpm install.

I'm doubtful that we could get by with an rpm script populating system.devices.  A command to do this scans disks on the system, which can be non-trivial, and I'm not sure it's safe to assume that all necessary disks are present at the time of the rpm install.

There are some other similar cases where we might like to recreate system.devices on first boot (bug 2213157, bug 2059545).  Even virt-sysprep, which is meant to solve this, will just remove system.devices and doesn't have a solution for recreating system.devices.  I've been thinking about some method were a temp file could be created in the image that would trigger lvm to recreate system.devices before using it. Maybe some of these ideas could be useful.

I've created bug 2224641 describing a method for lvm to automatically generate a system.devices file for the root VG, and it may be a solution for this case.

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.