Bug 2033737

Summary: 64-lvm.rules needs to handle md devices for root on lvm on md to work
Product: Red Hat Enterprise Linux 9 Reporter: David Teigland <teigland>
Component: dracutAssignee: Lukáš Nykrýn <lnykryn>
Status: CLOSED DUPLICATE QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 9.0CC: cmarthal, dracut-maint-list, dtardon, farrotin, gordon.messmer
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-02-04 16:12:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Teigland 2021-12-17 18:00:01 UTC
Description of problem:

In RHEL9 the lvm package has replaced 69-dm-lvm-metad.rules with 69-dm-lvm.rules, implementing a new style of lvm autoactivation.

In RHEL8, dracut included 69-dm-lvm-metad.rules in the initrd where it set LVM_MD_PV_ACTIVATED=1.  This allowed root-on-lvm-on-md to work (see bug 2032993).

RHEL9 is currently missing the LVM_MD_PV_ACTIVATED=1 step in the initrd since 69-dm-lvm-metad.rules is gone.  So, root-on-lvm-on-md is broken, and leads to boot timeouts when an LV is used that requires autoactivation (commonly for home.)

To fix this in RHEL9, the 64-lvm.rules file in dracut needs to be patched to include this line:

KERNEL=="md[0-9]*", ACTION=="change", ENV{ID_FS_TYPE}=="LVM2_member", ENV{LVM_MD_PV_ACTIVATED}!="1", TEST=="md/array_state", ENV{LVM_MD_PV_ACTIVATED}="1"

Here's what my full working 64-lvm.rules file looks like:

SUBSYSTEM!="block", GOTO="lvm_end"
ACTION!="add|change", GOTO="lvm_end"
KERNEL=="md[0-9]*", ACTION=="change", ENV{ID_FS_TYPE}=="LVM2_member", ENV{LVM_MD_PV_ACTIVATED}!="1", TEST=="md/array_state", ENV{LVM_MD_PV_ACTIVATED}="1"
# Also don't process disks that are slated to be a multipath device
ENV{DM_MULTIPATH_DEVICE_PATH}=="1", GOTO="lvm_end"
KERNEL=="dm-[0-9]*", ACTION=="add", GOTO="lvm_end"
ENV{ID_FS_TYPE}!="LVM?_member", GOTO="lvm_end"

PROGRAM=="/bin/sh -c 'for i in $sys/$devpath/holders/dm-[0-9]*; do [ -e $$i ] && exit 0; done; exit 1;' ", \
    GOTO="lvm_end"

RUN+="/sbin/initqueue --settled --onetime --unique /sbin/lvm_scan"
RUN+="/sbin/initqueue --timeout --name 51-lvm_scan --onetime --unique /sbin/lvm_scan --partial"
RUN+="/bin/sh -c '>/tmp/.lvm_scan-%k;'"

LABEL="lvm_end"


(I am working on a larger set of changes to the dracut lvm module upstream which will hopefully be suitable for rhel9.  This will remove the dracut code that attempts to include the non-existent 69-dm-lvm-metad.rules in the initrd, among other things.)

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 farrotin 2022-01-07 07:17:38 UTC
back from PTO and revisiting bugs opened for Stream 9 .. Do we have some kind of ETA for when new pkg will be available for Stream 9 users ?

Comment 2 David Teigland 2022-01-12 14:52:33 UTC
*** Bug 2039091 has been marked as a duplicate of this bug. ***

Comment 3 Gordon Messmer 2022-01-12 16:12:37 UTC
I can confirm that the change suggested in the description fixes bug 2039091.

Comment 4 farrotin 2022-01-18 16:10:54 UTC
just curious about status now : when can we expect newer dracut/lvm2 pkgs to be built and available for people to consume ? (just trying to plan when we can just deploy stream 9 for centos stream infra itself, which doesn't work as long as all pending bug reports aren't closed) :)

Comment 5 David Tardon 2022-02-04 16:12:24 UTC
We intend to backport the new lvm stuff for 9.0, so let's close this in favor of bug 2037955.

*** This bug has been marked as a duplicate of bug 2037955 ***