[CentOS] rd.lvm.lv on CentOS Stream 9 (first-boot failure)

Mon Jan 10 22:22:44 UTC 2022
Gordon Messmer <gordon.messmer at gmail.com>

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 

> 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.