CentOS - Jan 2022 - rd.lvm.lv on CentOS Stream 9 (first-boot failure)

I've install a CentOS Stream 9 system from a kickstart file that 
specified (among other things) several logical volumes:

logvol / --fstype="ext4" --size=10240 --name=lv_root --vgname=VolGroup
logvol /var --fstype="ext4" --size=4096 --name=lv_var
--vgname=VolGroup
logvol swap --fstype="swap" --size=2048 --name=lv_swap
--vgname=VolGroup

When that system rebooted, the kernel args did specify 
"rd.lvm.lv=VolGroup/lv_root rd.lvm.lv=VolGroup/lv_swap", but did not 
specify "rd.lvm.lv=VolGroup/lv_var", so boot failed because the 
filesystem required for /var couldn't be found.

The dracut.cmdline documentation does record that it will only activate 
the LVs given as "rd.lvm.lv", but I'm confused about several
things.

1: The system also includes a volume group named "BackupGroup" and
that
group activates on boot (post-dracut).? Why are those LVs activated when 
rd.lvm.lv is specified?
2: Why didn't Anaconda add the "var" LV to the kernel arguments?
3: This seems like a change from earlier releases, but I can't find any 
documentation to that effect.? Under CentOS 7, after dracut had 
finished, the remaining logical volumes in that group would be 
activated.? Because they aren't, currently, libvirtd cannot start any of 
its guests until I manually activate the group.? How can I restore the 
old behavior of activating all of the LVs on boot?

On 1/9/22 15:37, Gordon Messmer wrote:
> 1: The system also includes a volume group named "BackupGroup"
and
> that group activates on boot (post-dracut).? Why are those LVs 
> activated when rd.lvm.lv is specified?

As far as I can tell, this is because in the dracut boot process, the 
device backing VolGroup is activated, but the device backing BackupGroup 
is not.? As a result, the latter device triggers a udev event after the 
normal root FS is mounted, and udev creates a transient systemd unit to 
start the BackupGroup VG.? No udev event for VolGroup == no furter 
activation.

> 2: Why didn't Anaconda add the "var" LV to the kernel
arguments?

I still don't know the answer to this, but the current arrangement seems 
like a bug.? As far as I know, the LVs inside VolGroup can't be 
activated unless that VG is complete, and if it's complete, then I can 
see no good reason why Anaconda should add individual LVs to the kernel 
command line rather than "rd.lvm.vg=VolGroup".? Activating the group
as
a whole would fix both the boot failure resulting from lv_var not being 
activated, as well as the libvirt failure resulting from the guest LVs 
being absent.

Once I replaced Anaconda's boot args with "rd.lvm.vg=VolGroup",
the
system works properly.

> 3: This seems like a change from earlier releases, but I can't find 
> any documentation to that effect.? Under CentOS 7, after dracut had 
> finished, the remaining logical volumes in that group would be 
> activated.? Because they aren't, currently, libvirtd cannot start any 
> of its guests until I manually activate the group.? How can I restore 
> the old behavior of activating all of the LVs on boot?

I believe the regression is the result of deprecating lvmetad in favor 
of udev event-based activation.