Bug 1238441 - mdadm-last-resort@.timer is not started for degraded arrays
Summary: mdadm-last-resort@.timer is not started for degraded arrays
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: mdadm
Version: 22
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: XiaoNi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1337003 1337004 1340896
TreeView+ depends on / blocked
 
Reported: 2015-07-01 21:28 UTC by Nate Clark
Modified: 2016-07-19 19:51 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1337003 1337004 1340896 (view as bug list)
Environment:
Last Closed: 2016-07-19 19:51:53 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Nate Clark 2015-07-01 21:28:26 UTC
Description of problem:
The patch mdadm-3.3-udev.patch adds an unconditional GOTO md_inc_end in 64-md-raid-assembly.rules, which is where the rule to to add mdadm-last-resort.timer to systemd is located. Because the timer is never started a degraded raid will never be constructed by mdadm-last-resort.service.


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


How reproducible:
Always

Actual results:
mdadm-last-resort.timer is not started for any md device

Expected results:
mdadm-last-resort.timer is started for degraded md devices.

Comment 3 XiaoNi 2016-03-23 14:48:10 UTC
(In reply to Nate Clark from comment #0)
> Description of problem:
> The patch mdadm-3.3-udev.patch adds an unconditional GOTO md_inc_end in
> 64-md-raid-assembly.rules, which is where the rule to to add
> mdadm-last-resort.timer to systemd is located. Because the timer is never
> started a degraded raid will never be constructed by
> mdadm-last-resort.service.
> 

Hi Nate

The patch mdadm-3.3-udev.patch is not the reason which cause this problem.
Could you try this patch to your /usr/lib/udev/rules.d/65-md-incremental.rules

--- 65-md-incremental.rules     2015-10-06 02:02:45.000000000 +0800
+++ 65-md-incremental.rules~    2016-03-23 22:45:17.246905053 +0800
@@ -25,7 +25,8 @@
 # anything here, just regular disks, and this also won't get any imsm
 # array members either)
 SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_TYPE}=="linux_raid_member", \
-       RUN+="/sbin/mdadm -I $env{DEVNAME}"
+       IMPORT{program}="/sbin/mdadm -I $env{DEVNAME} --export $devnode --offroot ${DEVLINKS}"
+SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_TYPE}=="linux_raid_member", ENV{MD_STARTED}=="*unsafe*", ENV{MD_FOREIGN}=="no", ENV{SYSTEMD_WANTS}+="mdadm-last-resort@$env{MD_DEVICE}.timer"
 SUBSYSTEM=="block", ACTION=="remove", ENV{ID_PATH}=="?*", \
        ENV{ID_FS_TYPE}=="linux_raid_member", \
        RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}"

Thanks
Xiao

Comment 4 Nate Clark 2016-04-01 20:25:53 UTC
What version of the mdadm package is that diff based upon? mdadm-3.3.4-2, which is the latest for 22 and 23, does not have the rule to start the last-resort timer as seen in the base of the diff.

This is what that section of the udev rule is in 3.3.4-2

# anything here, just regular disks, and this also won't get any imsm
# array members either)
SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_TYPE}=="linux_raid_member", \
	RUN+="/sbin/mdadm -I $env{DEVNAME}"
SUBSYSTEM=="block", ACTION=="remove", ENV{ID_PATH}=="?*", \
	ENV{ID_FS_TYPE}=="linux_raid_member", \
	RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}"
SUBSYSTEM=="block", ACTION=="remove", ENV{ID_PATH}!="?*", \
	ENV{ID_FS_TYPE}=="linux_raid_member", \
	RUN+="/sbin/mdadm -If $name"

Comment 5 XiaoNi 2016-04-05 13:52:42 UTC
(In reply to Nate Clark from comment #4)
> What version of the mdadm package is that diff based upon? mdadm-3.3.4-2,
> which is the latest for 22 and 23, does not have the rule to start the
> last-resort timer as seen in the base of the diff.

The version I used is mdadm-3.3.4-3. I get it from the command fedpkg clone mdadm.

> 
> This is what that section of the udev rule is in 3.3.4-2
> 
> # anything here, just regular disks, and this also won't get any imsm
> # array members either)
> SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_TYPE}=="linux_raid_member", \


> 	RUN+="/sbin/mdadm -I $env{DEVNAME}"

Yes, you need to change the line to:

       IMPORT{program}="/sbin/mdadm -I $env{DEVNAME} --export $devnode --offroot ${DEVLINKS}"
SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_TYPE}=="linux_raid_member", ENV{MD_STARTED}=="*unsafe*", ENV{MD_FOREIGN}=="no", ENV{SYSTEMD_WANTS}+="mdadm-last-resort@$env{MD_DEVICE}.timer"

It can start the mdadm-last-resort timer.

Thanks
Xiao

Comment 6 Nate Clark 2016-04-08 17:21:28 UTC
Applying the patch:

diff --git a/mdadm.rules b/mdadm.rules
index 5f3950e..37e5884 100644
--- a/mdadm.rules
+++ b/mdadm.rules
@@ -25,7 +25,10 @@ ENV{DM_MULTIPATH_DEVICE_PATH}=="?*", GOTO="md_end"
 # anything here, just regular disks, and this also won't get any imsm
 # array members either)
 SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_TYPE}=="linux_raid_member", \
-       RUN+="/sbin/mdadm -I $env{DEVNAME}"
+       IMPORT{program}="/sbin/mdadm -I $env{DEVNAME} --export $devnode --offroot ${DEVLINKS}"
+SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_TYPE}=="linux_raid_member", \
+       ENV{MD_STARTED}=="*unsafe*", ENV{MD_FOREIGN}=="no", \
+       ENV{SYSTEMD_WANTS}+="mdadm-last-resort@$env{MD_DEVICE}.timer"
 SUBSYSTEM=="block", ACTION=="remove", ENV{ID_PATH}=="?*", \
        ENV{ID_FS_TYPE}=="linux_raid_member", \
        RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}"

To the current code in git://pkgs.fedoraproject.org/rpms/mdadm now starts the mdadm-last-resort@.timer for unsafe md devices.

Comment 7 Fedora Update System 2016-06-09 04:46:57 UTC
mdadm-3.3.4-3.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-f4a2bc1983

Comment 8 Fedora Update System 2016-06-10 03:24:01 UTC
mdadm-3.3.4-3.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-f4a2bc1983

Comment 9 Fedora End Of Life 2016-07-19 19:51:53 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.