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.