On 10/01/2022 23:22, Gordon Messmer wrote: > 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. > See multiple bugzilla reports open (including one in September) about some multiple issues all mixed all together : https://bugzilla.redhat.com/show_bug.cgi?id=2002640 https://bugzilla.redhat.com/show_bug.cgi?id=2033737 -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20220114/809518a5/attachment-0002.sig>