[prev in list] [next in list] [prev in thread] [next in thread]
List: centos
Subject: Re: [CentOS] rd.lvm.lv on CentOS Stream 9 (first-boot failure)
From: Fabian Arrotin <arrfab () centos ! org>
Date: 2022-01-14 9:54:02
Message-ID: 5a51f0e7-feed-6e9a-0889-4874abf01b1e () centos ! org
[Download RAW message or body]
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
[Attachment #2 (unknown)]
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
["OpenPGP_signature.asc" (application/pgp-signature)]
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
--===============4932586310571347266==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic