dcavalca / rpms / mdadm

Forked from rpms/mdadm 3 years ago
Clone

Blame SOURCES/mdadm.rules

1f6b6a
# This file causes block devices with Linux RAID (mdadm) signatures to
1f6b6a
# automatically cause mdadm to be run.
1f6b6a
# See udev(8) for syntax
1f6b6a
1f6b6a
# Don't process any events if anaconda is running as anaconda brings up
1f6b6a
# raid devices manually
1f6b6a
ENV{ANACONDA}=="?*", GOTO="md_end"
1f6b6a
1f6b6a
# Also don't process disks that are slated to be a multipath device
1f6b6a
ENV{DM_MULTIPATH_DEVICE_PATH}=="1", GOTO="md_end"
1f6b6a
1f6b6a
# We process add events on block devices (since they are ready as soon as
1f6b6a
# they are added to the system), but we must process change events as well
1f6b6a
# on any dm devices (like LUKS partitions or LVM logical volumes) and on
1f6b6a
# md devices because both of these first get added, then get brought live
1f6b6a
# and trigger a change event.  The reason we don't process change events
1f6b6a
# on bare hard disks is because if you stop all arrays on a disk, then
1f6b6a
# run fdisk on the disk to change the partitions, when fdisk exits it
1f6b6a
# triggers a change event, and we want to wait until all the fdisks on
1f6b6a
# all member disks are done before we do anything.  Unfortunately, we have
1f6b6a
# no way of knowing that, so we just have to let those arrays be brought
1f6b6a
# up manually after fdisk has been run on all of the disks.
1f6b6a
1f6b6a
# First, process all add events (md and dm devices will not really do
1f6b6a
# anything here, just regular disks, and this also won't get any imsm
1f6b6a
# array members either)
1f6b6a
SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_TYPE}=="linux_raid_member", \
1f6b6a
	IMPORT{program}="/sbin/mdadm -I $env{DEVNAME} --export $devnode --offroot ${DEVLINKS}"
1f6b6a
SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_TYPE}=="linux_raid_member", \
1f6b6a
	ENV{MD_STARTED}=="*unsafe*", ENV{MD_FOREIGN}=="no", ENV{SYSTEMD_WANTS}+="mdadm-last-resort@$env{MD_DEVICE}.timer"
1f6b6a
SUBSYSTEM=="block", ACTION=="remove", ENV{ID_PATH}=="?*", \
1f6b6a
	ENV{ID_FS_TYPE}=="linux_raid_member", \
1f6b6a
	RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}"
1f6b6a
SUBSYSTEM=="block", ACTION=="remove", ENV{ID_PATH}!="?*", \
1f6b6a
	ENV{ID_FS_TYPE}=="linux_raid_member", \
1f6b6a
	RUN+="/sbin/mdadm -If $name"
1f6b6a
1f6b6a
# Next, check to make sure the BIOS raid stuff wasn't turned off via cmdline
1f6b6a
IMPORT{cmdline}="noiswmd"
1f6b6a
IMPORT{cmdline}="nodmraid"
1f6b6a
ENV{noiswmd}=="?*", GOTO="md_imsm_inc_end"
1f6b6a
ENV{nodmraid}=="?*", GOTO="md_imsm_inc_end"
1f6b6a
SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_TYPE}=="isw_raid_member", \
1f6b6a
	RUN+="/sbin/mdadm -I $env{DEVNAME}"
5eacff
SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_TYPE}=="ddf_raid_member", \
5eacff
	RUN+="/sbin/mdadm -I $env{DEVNAME}"
1f6b6a
SUBSYSTEM=="block", ACTION=="remove", ENV{ID_PATH}=="?*", \
1f6b6a
	ENV{ID_FS_TYPE}=="isw_raid_member", \
1f6b6a
	RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}"
1f6b6a
SUBSYSTEM=="block", ACTION=="remove", ENV{ID_PATH}!="?*", \
1f6b6a
	ENV{ID_FS_TYPE}=="isw_raid_member", \
1f6b6a
	RUN+="/sbin/mdadm -If $name"
1f6b6a
LABEL="md_imsm_inc_end"
1f6b6a
1f6b6a
# Next make sure that this isn't a dm device we should skip for some reason
1f6b6a
ENV{DM_UDEV_RULES_VSN}!="?*", GOTO="dm_change_end"
1f6b6a
ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", GOTO="dm_change_end"
1f6b6a
ENV{DM_SUSPENDED}=="1", GOTO="dm_change_end"
1f6b6a
KERNEL=="dm-*", SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="linux_raid_member", \
1f6b6a
	ACTION=="change", RUN+="/sbin/mdadm -I $env{DEVNAME}"
1f6b6a
LABEL="dm_change_end"
1f6b6a
1f6b6a
# Finally catch any nested md raid arrays.  If we brought up an md raid
1f6b6a
# array that's part of another md raid array, it won't be ready to be used
1f6b6a
# until the change event that occurs when it becomes live
1f6b6a
KERNEL=="md*", SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="linux_raid_member", \
1f6b6a
	ACTION=="change", RUN+="/sbin/mdadm -I $env{DEVNAME}"
1f6b6a
1f6b6a
LABEL="md_end"