Additional patches for 10.3 lvm2
Resolves: RHEL-163449
This commit is contained in:
Marian Csontos
parent
ac2cf6d075
commit
80e131be0b
@ -1,7 +1,7 @@
|
||||
From 211f417e31f269fc0fae6c315fc2ad3c625a2426 Mon Sep 17 00:00:00 2001
|
||||
From: Marian Csontos <mcsontos@redhat.com>
|
||||
Date: Fri, 15 May 2026 14:47:48 +0200
|
||||
Subject: [PATCH] RHEL10
|
||||
Subject: [PATCH 1/5] RHEL10
|
||||
|
||||
---
|
||||
VERSION | 2 +-
|
||||
|
||||
46
0002-lvmlockd-fix-adopt-failure-when-gl-is-not-found.patch
Normal file
46
0002-lvmlockd-fix-adopt-failure-when-gl-is-not-found.patch
Normal file
@ -0,0 +1,46 @@
|
||||
From 3e5b9e9816788762eca1fc92ac5f18223c7ede87 Mon Sep 17 00:00:00 2001
|
||||
From: David Teigland <teigland@redhat.com>
|
||||
Date: Wed, 20 May 2026 10:50:51 -0500
|
||||
Subject: [PATCH 2/5] lvmlockd: fix adopt failure when gl is not found
|
||||
|
||||
When GL was not enabled in any started lockspace (e.g. after
|
||||
gl-disable), and lvmlockd restarted with adopt (-A 1), the GL
|
||||
lock adopt action failed with -ENOLS because no lockspace was
|
||||
found for the GL. This error fell through to the general error
|
||||
handler which incremented count_adopt_fail, causing the entire
|
||||
adopt to fail with "adopt_locks failed, reset host".
|
||||
|
||||
Handle -ENOLS for GL lock adopt as a normal condition rather
|
||||
than a fatal error. In the adopt flow, all lockspaces found
|
||||
in the lock manager have already been started, so -ENOLS means
|
||||
there is no orphan GL lock to adopt.
|
||||
|
||||
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
||||
(cherry picked from commit 4ea7fcc916f6f6286bb9354afd4a630254526df5)
|
||||
---
|
||||
daemons/lvmlockd/lvmlockd-core.c | 9 +++++++++
|
||||
1 file changed, 9 insertions(+)
|
||||
|
||||
diff --git a/daemons/lvmlockd/lvmlockd-core.c b/daemons/lvmlockd/lvmlockd-core.c
|
||||
index d46ce6daa..469610643 100644
|
||||
--- a/daemons/lvmlockd/lvmlockd-core.c
|
||||
+++ b/daemons/lvmlockd/lvmlockd-core.c
|
||||
@@ -6932,6 +6932,15 @@ static void adopt_locks(void)
|
||||
count_adopt_done++;
|
||||
free_action(act);
|
||||
|
||||
+ } else if (act->result == -ENOLS && act->rt == LD_RT_GL) {
|
||||
+ /*
|
||||
+ * No started lockspace has gl enabled, so there is
|
||||
+ * no orphan gl lock to adopt.
|
||||
+ */
|
||||
+ log_debug("Did not adopt gl lock, no gl lockspace found");
|
||||
+ count_adopt_done++;
|
||||
+ free_action(act);
|
||||
+
|
||||
} else if (act->result < 0) {
|
||||
/*
|
||||
* Some unexpected error.
|
||||
--
|
||||
2.54.0
|
||||
|
||||
@ -0,0 +1,40 @@
|
||||
From c8e4ca5ecfafd55896e8781512176f5013895784 Mon Sep 17 00:00:00 2001
|
||||
From: Peter Rajnoha <prajnoha@redhat.com>
|
||||
Date: Mon, 18 May 2026 09:47:50 +0200
|
||||
Subject: [PATCH 3/5] udev: check MD array_state value instead of just file
|
||||
existence
|
||||
|
||||
Replace TEST=="md/array_state" with ATTR{md/array_state}!="clear*|inactive"
|
||||
to verify the MD array is actually in a usable state, not just that the
|
||||
sysfs file exists. The "clear" and "inactive" states indicate the array
|
||||
is not assembled or not running.
|
||||
|
||||
This is the same check used by the MD udev rules themselves in
|
||||
/lib/udev/rules.d/63-md-raid-arrays.rules:
|
||||
ATTR{md/array_state}=="clear*|inactive", ENV{SYSTEMD_READY}="0", GOTO="md_end"
|
||||
|
||||
Using ATTR also makes the separate TEST check unnecessary because ATTR
|
||||
match fails when the sysfs attribute does not exist, which correctly
|
||||
prevents scanning in that case.
|
||||
|
||||
(cherry picked from commit f55287379cc2a9d65c9d43e1f5ba1428b4596808)
|
||||
---
|
||||
udev/69-dm-lvm.rules.in | 2 +-
|
||||
1 file changed, 1 insertion(+), 1 deletion(-)
|
||||
|
||||
diff --git a/udev/69-dm-lvm.rules.in b/udev/69-dm-lvm.rules.in
|
||||
index adcf63453..6a53a4e3e 100644
|
||||
--- a/udev/69-dm-lvm.rules.in
|
||||
+++ b/udev/69-dm-lvm.rules.in
|
||||
@@ -45,7 +45,7 @@ LABEL="next"
|
||||
KERNEL!="md[0-9]*", GOTO="next"
|
||||
IMPORT{db}="LVM_MD_PV_ACTIVATED"
|
||||
ACTION=="add", ENV{LVM_MD_PV_ACTIVATED}=="1", GOTO="lvm_scan"
|
||||
-ACTION=="change", ENV{LVM_MD_PV_ACTIVATED}!="1", TEST=="md/array_state", ENV{LVM_MD_PV_ACTIVATED}="1", GOTO="lvm_scan"
|
||||
+ACTION=="change", ENV{LVM_MD_PV_ACTIVATED}!="1", ATTR{md/array_state}!="clear*|inactive", ENV{LVM_MD_PV_ACTIVATED}="1", GOTO="lvm_scan"
|
||||
ACTION=="add", KERNEL=="md[0-9]*p[0-9]*", GOTO="lvm_scan"
|
||||
GOTO="lvm_end"
|
||||
|
||||
--
|
||||
2.54.0
|
||||
|
||||
@ -0,0 +1,58 @@
|
||||
From 24477da9128dad45547e0586dd8097b40534883f Mon Sep 17 00:00:00 2001
|
||||
From: Peter Rajnoha <prajnoha@redhat.com>
|
||||
Date: Mon, 18 May 2026 09:51:41 +0200
|
||||
Subject: [PATCH 4/5] udev: MD and loop fallback handling for synthetic ADD
|
||||
events if udev db records missing
|
||||
|
||||
Add a fallback for synthetic add events on MD and loop devices in
|
||||
case udev has no records about LVM_MD_PV_ACTIVATED or
|
||||
LVM_LOOP_PV_ACTIVATED.
|
||||
|
||||
A synthetic event is one generated by userspace (e.g. udevadm trigger
|
||||
during coldplug) rather than a genuine kernel udev event. Such events
|
||||
have SYNTH_UUID set in the udev event environment which distinguishes
|
||||
them from real kernel-originated events.
|
||||
|
||||
This fallback is needed when a device is activated while the udev
|
||||
daemon is not running. One such case is the initrd to root filesystem
|
||||
switch over where the udev daemon from initrd is stopped and a new
|
||||
instance is started from the real root filesystem. During this period,
|
||||
udev is not running and any device activation that occurs will not be
|
||||
recorded, so the activation flags will be missing from the udev
|
||||
database. When the new udev instance starts and udevadm trigger runs,
|
||||
it generates synthetic add events instead of change events. These
|
||||
synthetic events need to check device readiness directly
|
||||
(md/array_state or loop/backing_file) and set the activation flag
|
||||
so that PV scanning proceeds.
|
||||
|
||||
Without this, the LVM scan is missed for PVs on such MD or loop
|
||||
devices, preventing event-based autoactivation.
|
||||
|
||||
(cherry picked from commit e278fa46fab21a779ba0f597b415057c2e3ce3a1)
|
||||
---
|
||||
udev/69-dm-lvm.rules.in | 2 ++
|
||||
1 file changed, 2 insertions(+)
|
||||
|
||||
diff --git a/udev/69-dm-lvm.rules.in b/udev/69-dm-lvm.rules.in
|
||||
index 6a53a4e3e..a817d59ea 100644
|
||||
--- a/udev/69-dm-lvm.rules.in
|
||||
+++ b/udev/69-dm-lvm.rules.in
|
||||
@@ -45,6 +45,7 @@ LABEL="next"
|
||||
KERNEL!="md[0-9]*", GOTO="next"
|
||||
IMPORT{db}="LVM_MD_PV_ACTIVATED"
|
||||
ACTION=="add", ENV{LVM_MD_PV_ACTIVATED}=="1", GOTO="lvm_scan"
|
||||
+ACTION=="add", ENV{LVM_MD_PV_ACTIVATED}!="1", ENV{SYNTH_UUID}!="", ATTR{md/array_state}!="clear*|inactive", ENV{LVM_MD_PV_ACTIVATED}="1", GOTO="lvm_scan"
|
||||
ACTION=="change", ENV{LVM_MD_PV_ACTIVATED}!="1", ATTR{md/array_state}!="clear*|inactive", ENV{LVM_MD_PV_ACTIVATED}="1", GOTO="lvm_scan"
|
||||
ACTION=="add", KERNEL=="md[0-9]*p[0-9]*", GOTO="lvm_scan"
|
||||
GOTO="lvm_end"
|
||||
@@ -54,6 +55,7 @@ LABEL="next"
|
||||
KERNEL!="loop[0-9]*", GOTO="next"
|
||||
IMPORT{db}="LVM_LOOP_PV_ACTIVATED"
|
||||
ACTION=="add", ENV{LVM_LOOP_PV_ACTIVATED}=="1", GOTO="lvm_scan"
|
||||
+ACTION=="add", ENV{LVM_LOOP_PV_ACTIVATED}!="1", ENV{SYNTH_UUID}!="", TEST=="loop/backing_file", ENV{LVM_LOOP_PV_ACTIVATED}="1", GOTO="lvm_scan"
|
||||
ACTION=="change", ENV{LVM_LOOP_PV_ACTIVATED}!="1", TEST=="loop/backing_file", ENV{LVM_LOOP_PV_ACTIVATED}="1", GOTO="lvm_scan"
|
||||
GOTO="lvm_end"
|
||||
|
||||
--
|
||||
2.54.0
|
||||
|
||||
26
0005-WHATS_NEW-update.patch
Normal file
26
0005-WHATS_NEW-update.patch
Normal file
@ -0,0 +1,26 @@
|
||||
From 5905e22abb0b53a7c1ae66105930da895efcf65e Mon Sep 17 00:00:00 2001
|
||||
From: Peter Rajnoha <prajnoha@redhat.com>
|
||||
Date: Tue, 26 May 2026 09:49:28 +0200
|
||||
Subject: [PATCH 5/5] WHATS_NEW: update
|
||||
|
||||
(cherry picked from commit 8ee64a912c0e2e6dbeee5f36f8e15893d787a966)
|
||||
---
|
||||
WHATS_NEW | 5 +++++
|
||||
1 file changed, 5 insertions(+)
|
||||
|
||||
diff --git a/WHATS_NEW b/WHATS_NEW
|
||||
index cd4850634..e53280e10 100644
|
||||
--- a/WHATS_NEW
|
||||
+++ b/WHATS_NEW
|
||||
@@ -1,3 +1,8 @@
|
||||
+Version 2.03.42 -
|
||||
+==================
|
||||
+ Fix autoactivation on top of MD and loop devices if udev db records incomplete.
|
||||
+ Make MD device ready state check in udev to be in sync with MD udev rules.
|
||||
+
|
||||
Version 2.03.41 - 15th May 2026
|
||||
===============================
|
||||
Allow `lvchange --syncaction repair` on RAID LVs with integrity.
|
||||
--
|
||||
2.54.0
|
||||
|
||||
@ -45,6 +45,10 @@ License: GPL-2.0-only
|
||||
URL: https://sourceware.org/lvm2
|
||||
Source0: https://sourceware.org/pub/lvm2/releases/LVM2.%{version}.tgz
|
||||
Patch1: 0001-RHEL10.patch
|
||||
Patch2: 0002-lvmlockd-fix-adopt-failure-when-gl-is-not-found.patch
|
||||
Patch3: 0003-udev-check-MD-array_state-value-instead-of-just-file.patch
|
||||
Patch4: 0004-udev-MD-and-loop-fallback-handling-for-synthetic-ADD.patch
|
||||
Patch5: 0005-WHATS_NEW-update.patch
|
||||
|
||||
BuildRequires: make
|
||||
BuildRequires: gcc
|
||||
@ -656,6 +660,9 @@ An extensive functional testsuite for LVM2.
|
||||
%endif
|
||||
|
||||
%changelog
|
||||
* Tue Jun 02 2026 Marian Csontos <mcsontos@redhat.com> - 2.03.41-2
|
||||
- Fix MD handling in udev rules.
|
||||
|
||||
* Fri May 15 2026 Marian Csontos <mcsontos@redhat.com> - 2.03.41-1
|
||||
- Update to upstream version 2.03.41.
|
||||
- See WHATS_NEW and WHATS_NEW_DM for more information.
|
||||
|
||||
@ -49,4 +49,4 @@ prepare:
|
||||
- systemd-devel
|
||||
- systemd-units
|
||||
- device-mapper-persistent-data
|
||||
- sanlock-devel
|
||||
#- sanlock-devel
|
||||
|
||||
Loading…
Reference in New Issue
Block a user