2009-11-01 21:01:31 +03:00
# Copyright (C) 2009 Red Hat, Inc. All rights reserved.
#
# This file is part of LVM2.
2009-08-03 22:44:54 +04:00
# Udev rules for device-mapper devices.
#
# These rules create a DM control node in /dev/(DM_DIR) directory.
# The rules also create nodes named dm-x (x is a number) in /dev
# directory and symlinks to these nodes with names given by
# the actual DM names. Some udev environment variables are set
# for use in later rules:
# DM_NAME - actual DM device's name
# DM_UUID - UUID set for DM device (blank if not specified)
# DM_SUSPENDED - suspended state of DM device (0 or 1)
2009-09-11 20:05:20 +04:00
# DM_UDEV_RULES_VSN - DM udev rules version
2009-08-03 22:44:54 +04:00
KERNEL=="device-mapper", NAME="(DM_DIR)/control"
SUBSYSTEM!="block", GOTO="dm_end"
KERNEL!="dm-[0-9]*", GOTO="dm_end"
2012-06-22 13:50:02 +04:00
(DM_EXEC_RULE)
2009-09-11 20:05:20 +04:00
2010-06-23 21:00:32 +04:00
# Device created, major and minor number assigned - "add" event generated.
# Table loaded - no event generated.
# Device resumed (or renamed) - "change" event generated.
# Device removed - "remove" event generated.
#
# The dm-X nodes are always created, even on "add" event, we can't suppress
# that (the node is created even earlier with devtmpfs). All the symlinks
# (e.g. /dev/mapper) are created in right time after a device has its table
# loaded and is properly resumed. For this reason, direct use of dm-X nodes
# is not recommended.
2009-08-03 22:44:54 +04:00
ACTION!="add|change", GOTO="dm_end"
2011-08-11 21:55:29 +04:00
# Decode udev control flags and set environment variables appropriately.
# These flags are encoded in DM_COOKIE variable that was introduced in
# kernel version 2.6.31. Therefore, we can use this feature with
# kernels >= 2.6.31 only. Cookie is not decoded for remove event.
2012-06-22 13:50:02 +04:00
ENV{DM_COOKIE}=="?*", IMPORT{program}="(DM_EXEC)/dmsetup udevflags $env{DM_COOKIE}"
2011-08-11 21:55:29 +04:00
2010-08-12 17:07:08 +04:00
# Rule out easy-to-detect inappropriate events first.
ENV{DISK_RO}=="1", GOTO="dm_disable"
2010-04-28 17:37:36 +04:00
# There is no cookie set nor any flags encoded in events not originating
# in libdevmapper so we need to detect this and try to behave correctly.
# For such spurious events, regenerate all flags from current udev database content
# (this information would normally be inaccessible for spurious ADD and CHANGE events).
2012-12-21 13:34:48 +04:00
ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}=="1", ENV{DM_ACTIVATION}="1", GOTO="dm_flags_done"
2010-04-28 17:37:36 +04:00
IMPORT{db}="DM_UDEV_DISABLE_DM_RULES_FLAG"
IMPORT{db}="DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG"
IMPORT{db}="DM_UDEV_DISABLE_DISK_RULES_FLAG"
IMPORT{db}="DM_UDEV_DISABLE_OTHER_RULES_FLAG"
IMPORT{db}="DM_UDEV_LOW_PRIORITY_FLAG"
IMPORT{db}="DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG"
2010-06-23 21:00:32 +04:00
IMPORT{db}="DM_UDEV_PRIMARY_SOURCE_FLAG"
2010-04-28 17:37:36 +04:00
IMPORT{db}="DM_UDEV_FLAG7"
IMPORT{db}="DM_SUBSYSTEM_UDEV_FLAG0"
IMPORT{db}="DM_SUBSYSTEM_UDEV_FLAG1"
IMPORT{db}="DM_SUBSYSTEM_UDEV_FLAG2"
IMPORT{db}="DM_SUBSYSTEM_UDEV_FLAG3"
IMPORT{db}="DM_SUBSYSTEM_UDEV_FLAG4"
IMPORT{db}="DM_SUBSYSTEM_UDEV_FLAG5"
IMPORT{db}="DM_SUBSYSTEM_UDEV_FLAG6"
IMPORT{db}="DM_SUBSYSTEM_UDEV_FLAG7"
2010-08-12 17:41:18 +04:00
IMPORT{db}="DM_UDEV_RULES_VSN"
2010-04-28 17:37:36 +04:00
LABEL="dm_flags_done"
2010-06-23 21:00:32 +04:00
# Normally, we operate on "change" events. But when coldplugging, there's an
# "add" event present. We have to recognize this and do our actions in this
# particular situation, too. Also, we don't want the nodes to be created
# prematurely on "add" events while not coldplugging. We check
# DM_UDEV_PRIMARY_SOURCE_FLAG to see if the device was activated correctly
# before and if not, we ignore the "add" event totally. This way we can support
# udev triggers generating "add" events (e.g. "udevadm trigger --action=add" or
# "echo add > /sys/block/<dm_device>/uevent"). The trigger with "add" event is
# also used at boot to reevaluate udev rules for all existing devices activated
# before (e.g. in initrd). If udev is used in initrd, we require the udev init
# script to not remove the existing udev database so we can reuse the information
# stored at the time of device activation in the initrd.
2013-05-03 13:01:57 +04:00
# The DM_ACTIVATION variable tells when any device stacked above should be
# (re)activated as well.
udev: also autoactivate on coldplug
Commit 756bcabbfe297688ba240a880bc2b55265ad33f0 fixed autoactivation
to not trigger on each uevent for a PV that appeared in the system
most notably the events that are triggered artificially (udevadm
trigger or as the result of the WATCH udev rule being applied that
consequently generates CHANGE uevents). This fixed a situation in
which VGs/LVs were activated when they should not.
BUT we still need to care about the coldplug used at boot to
retrigger the ADD events - the "udevadm trigger --action=add"!
For non-DM-based PVs, this is already covered as for these we
run the autoactivation on ADD event only.
However, for DM-based PVs, we still need to run the
autoactivation even for the artificial ADD event, reusing
the udev DB content from previous proper CHANGE event that
came with the DM device activation.
Simply, this patch fixes a situation in which we run extra
"udevadm trigger --action=add" (or echo add > /sys/block/<dev>/uevent)
for DM-based PVs (cryptsetup devices, multipath devices, any
other DM devices...).
Without this patch, while using lvmetad + autoactivation,
any VG/LV that has a DM-based PV and for which we do not
call the activation directly, the VG/LV is not activated.
For example a VG with an LV with root FS on it which is directly
activated in initrd and then missing activation of the rest
of the LVs in the VG because of unhandled uevent retrigger on
boot after switching to root FS (the "coldplug").
(No WHATS_NEW here as this fixes the commit mentioned
above and which was not released yet.)
2013-04-19 14:17:53 +04:00
ACTION!="add", GOTO="dm_no_coldplug"
ENV{DM_UDEV_RULES_VSN}!="1", ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="1", GOTO="dm_disable"
ENV{DM_ACTIVATION}="1"
LABEL="dm_no_coldplug"
2009-08-03 22:44:54 +04:00
2013-05-03 13:01:57 +04:00
# Putting it together, following table is used to recognize genuine and spurious events.
# N.B. Spurious events are generated based on use of the WATCH udev
# rule or by triggering an event manually by "udevadm trigger" call
# or by "echo <event_name> > /sys/block/dm-X/uevent".
#
# EVENT DM_UDEV_PRIMARY_SOURCE_FLAG DM_ACTIVATION
# ======================================================================
# add event (genuine) 0 0
# change event (genuine) 1 1
# add event (spurious)
# |_ dev still not active 0 0
# \_ dev already active 1 1
# change event (spurious)
# |_ dev still not active 0 0
# \_ dev already active 1 0
2009-08-03 22:44:54 +04:00
# "dm" sysfs subdirectory is available in newer versions of DM
# only (kernels >= 2.6.29). We have to check for its existence
# and use dmsetup tool instead to get the DM name, uuid and
# suspended state if the "dm" subdirectory is not present.
2009-08-04 12:05:06 +04:00
# The "suspended" item was added even later (kernels >= 2.6.31),
2009-08-03 22:44:54 +04:00
# so we also have to call dmsetup if the kernel version used
# is in between these releases.
TEST=="dm", ENV{DM_NAME}="$attr{dm/name}", ENV{DM_UUID}="$attr{dm/uuid}", ENV{DM_SUSPENDED}="$attr{dm/suspended}"
2012-06-22 13:50:02 +04:00
TEST!="dm", IMPORT{program}="(DM_EXEC)/dmsetup info -j %M -m %m -c --nameprefixes --noheadings --rows -o name,uuid,suspended"
ENV{DM_SUSPENDED}!="?*", IMPORT{program}="(DM_EXEC)/dmsetup info -j %M -m %m -c --nameprefixes --noheadings --rows -o suspended"
2009-08-03 22:44:54 +04:00
# dmsetup tool provides suspended state information in textual
# form with values "Suspended"/"Active". We translate it to
# 0/1 respectively to be consistent with sysfs values.
ENV{DM_SUSPENDED}=="Active", ENV{DM_SUSPENDED}="0"
ENV{DM_SUSPENDED}=="Suspended", ENV{DM_SUSPENDED}="1"
2009-09-11 20:05:20 +04:00
# This variable provides a reliable way to check that device-mapper
# rules were installed. It means that all needed variables are set
# by these rules directly so there's no need to acquire them again
# later. Other rules can alternate the functionality based on this
# fact (e.g. fallback to rules that behave correctly even without
# these rules installed). It also provides versioning for any
# possible future changes.
2010-08-12 17:41:18 +04:00
# VSN 1 - original rules
# VSN 2 - add support for synthesized events
ENV{DM_UDEV_RULES_VSN}="2"
2009-09-11 20:05:20 +04:00
2009-10-26 17:29:33 +03:00
ENV{DM_UDEV_DISABLE_DM_RULES_FLAG}!="1", ENV{DM_NAME}=="?*", SYMLINK+="(DM_DIR)/$env{DM_NAME}"
2009-08-03 22:44:54 +04:00
2009-10-22 17:11:33 +04:00
# We have to ignore further rule application for inappropriate events
# and devices. But still send the notification if cookie exists.
2009-10-26 17:29:33 +03:00
ENV{DM_UUID}=="mpath-?*", ENV{DM_ACTION}=="PATH_FAILED", GOTO="dm_disable"
ENV{DM_UUID}=="CRYPT-TEMP-?*", GOTO="dm_disable"
ENV{DM_UUID}!="?*", ENV{DM_NAME}=="temporary-cryptsetup-?*", GOTO="dm_disable"
2009-09-11 20:05:20 +04:00
2011-01-28 14:41:51 +03:00
# Avoid processing and scanning a DM device in the other (foreign)
# rules if it is in suspended state. However, we still keep 'disk'
# and 'DM subsystem' related rules enabled in this case.
ENV{DM_SUSPENDED}=="1", ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}="1"
2009-09-11 20:05:20 +04:00
GOTO="dm_end"
2009-10-26 17:29:33 +03:00
LABEL="dm_disable"
ENV{DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG}="1"
ENV{DM_UDEV_DISABLE_DISK_RULES_FLAG}="1"
ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}="1"
2010-07-07 15:22:46 +04:00
OPTIONS:="nowatch"
2009-09-11 20:05:20 +04:00
2009-08-03 22:44:54 +04:00
LABEL="dm_end"