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.