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

Fri Jan 14 09:54:02 UTC 2022
Fabian Arrotin <arrfab at centos.org>

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 :


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>