IMG/cpio/ventoy/hook/default/10-dm.rules

   1 # Copyright (C) 2009 Red Hat, Inc. All rights reserved.
   2 #
   3 # This file is part of LVM2.
   4
   5 # Udev rules for device-mapper devices.
   6 #
   7 # These rules create a DM control node in /dev/mapper directory.
   8 # The rules also create nodes named dm-x (x is a number) in /dev
   9 # directory and symlinks to these nodes with names given by
  10 # the actual DM names. Some udev environment variables are set
  11 # for use in later rules:
  12 #   DM_NAME - actual DM device's name
  13 #   DM_UUID - UUID set for DM device (blank if not specified)
  14 #   DM_SUSPENDED - suspended state of DM device (0 or 1)
  15 #   DM_UDEV_RULES_VSN - DM udev rules version
  16 #
  17 # These rules cover only basic device-mapper functionality in udev.
  18 #
  19 # Various DM subsystems may contain further subsystem-specific rules
  20 # in 11-dm-<subsystem_name>.rules which should be installed together
  21 # with the DM subsystem and which extend these basic rules.
  22 # For example:
  23 #   11-dm-lvm.rules for LVM subsystem
  24 #   11-dm-mpath.rules for multipath subsystem (since version 0.6.0, recommended!)
  25 #
  26 # Even more specific rules may be required by subsystems so always
  27 # check subsystem's upstream repository for recent set of rules.
  28 # Also, keep in mind that recent rules may also require recent
  29 # subsystem-specific binaries.
  30
  31 KERNEL=="device-mapper", NAME="mapper/control"
  32
  33 SUBSYSTEM!="block", GOTO="dm_end"
  34 KERNEL!="dm-[0-9]*", GOTO="dm_end"
  35
  36
  37 # Device created, major and minor number assigned - "add" event generated.
  38 # Table loaded - no event generated.
  39 # Device resumed (or renamed) - "change" event generated.
  40 # Device removed - "remove" event generated.
  41 #
  42 # The dm-X nodes are always created, even on "add" event, we can't suppress
  43 # that (the node is created even earlier with devtmpfs). All the symlinks
  44 # (e.g. /dev/mapper) are created in right time after a device has its table
  45 # loaded and is properly resumed. For this reason, direct use of dm-X nodes
  46 # is not recommended.
  47 ACTION!="add|change", GOTO="dm_end"
  48
  49 # Decode udev control flags and set environment variables appropriately.
  50 # These flags are encoded in DM_COOKIE variable that was introduced in
  51 # kernel version 2.6.31. Therefore, we can use this feature with
  52 # kernels >= 2.6.31 only. Cookie is not decoded for remove event.
  53 ENV{DM_COOKIE}=="?*", IMPORT{program}="/usr/sbin/dmsetup udevflags $env{DM_COOKIE}"
  54
  55 # Rule out easy-to-detect inappropriate events first.
  56 ENV{DISK_RO}=="1", GOTO="dm_disable"
  57
  58 # There is no cookie set nor any flags encoded in events not originating
  59 # in libdevmapper so we need to detect this and try to behave correctly.
  60 # For such spurious events, regenerate all flags from current udev database content
  61 # (this information would normally be inaccessible for spurious ADD and CHANGE events).
  62 ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}=="1", ENV{DM_ACTIVATION}="1", GOTO="dm_flags_done"
  63 IMPORT{db}="DM_UDEV_DISABLE_DM_RULES_FLAG"
  64 IMPORT{db}="DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG"
  65 IMPORT{db}="DM_UDEV_DISABLE_DISK_RULES_FLAG"
  66 IMPORT{db}="DM_UDEV_DISABLE_OTHER_RULES_FLAG"
  67 IMPORT{db}="DM_UDEV_LOW_PRIORITY_FLAG"
  68 IMPORT{db}="DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG"
  69 IMPORT{db}="DM_UDEV_PRIMARY_SOURCE_FLAG"
  70 IMPORT{db}="DM_UDEV_FLAG7"
  71 IMPORT{db}="DM_UDEV_RULES_VSN"
  72 LABEL="dm_flags_done"
  73
  74 # Normally, we operate on "change" events. But when coldplugging, there's an
  75 # "add" event present. We have to recognize this and do our actions in this
  76 # particular situation, too. Also, we don't want the nodes to be created
  77 # prematurely on "add" events while not coldplugging. We check
  78 # DM_UDEV_PRIMARY_SOURCE_FLAG to see if the device was activated correctly
  79 # before and if not, we ignore the "add" event totally. This way we can support
  80 # udev triggers generating "add" events (e.g. "udevadm trigger --action=add" or
  81 # "echo add > /sys/block/<dm_device>/uevent"). The trigger with "add" event is
  82 # also used at boot to reevaluate udev rules for all existing devices activated
  83 # before (e.g. in initrd). If udev is used in initrd, we require the udev init
  84 # script to not remove the existing udev database so we can reuse the information
  85 # stored at the time of device activation in the initrd.
  86 ACTION!="add", GOTO="dm_no_coldplug"
  87 ENV{DM_UDEV_RULES_VSN}!="1", ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="1", GOTO="dm_disable"
  88 ENV{DM_ACTIVATION}="1"
  89 LABEL="dm_no_coldplug"
  90
  91 # Putting it together, following table is used to recognize genuine and spurious events.
  92 # N.B. Spurious events are generated based on use of the WATCH udev
  93 # rule or by triggering an event manually by "udevadm trigger" call
  94 # or by "echo <event_name> > /sys/block/dm-X/uevent".
  95 #
  96 #        EVENT              DM_UDEV_PRIMARY_SOURCE_FLAG   DM_ACTIVATION
  97 # ======================================================================
  98 # add event (genuine)                  0                        0
  99 # change event (genuine)               1                        1
 100 # add event (spurious)
 101 #   |_ dev still not active            0                        0
 102 #   \_ dev already active              1                        1
 103 # change event (spurious)
 104 #   |_ dev still not active            0                        0
 105 #   \_ dev already active              1                        0
 106
 107 # "dm" sysfs subdirectory is available in newer versions of DM
 108 # only (kernels >= 2.6.29). We have to check for its existence
 109 # and use dmsetup tool instead to get the DM name, uuid and
 110 # suspended state if the "dm" subdirectory is not present.
 111 # The "suspended" item was added even later (kernels >= 2.6.31),
 112 # so we also have to call dmsetup if the kernel version used
 113 # is in between these releases.
 114 TEST=="dm", ENV{DM_NAME}="$attr{dm/name}", ENV{DM_UUID}="$attr{dm/uuid}", ENV{DM_SUSPENDED}="$attr{dm/suspended}"
 115 TEST!="dm", IMPORT{program}="/usr/sbin/dmsetup info -j %M -m %m -c --nameprefixes --noheadings --rows -o name,uuid,suspended"
 116 ENV{DM_SUSPENDED}!="?*", IMPORT{program}="/usr/sbin/dmsetup info -j %M -m %m -c --nameprefixes --noheadings --rows -o suspended"
 117
 118 # dmsetup tool provides suspended state information in textual
 119 # form with values "Suspended"/"Active". We translate it to
 120 # 0/1 respectively to be consistent with sysfs values.
 121 ENV{DM_SUSPENDED}=="Active", ENV{DM_SUSPENDED}="0"
 122 ENV{DM_SUSPENDED}=="Suspended", ENV{DM_SUSPENDED}="1"
 123
 124 # This variable provides a reliable way to check that device-mapper
 125 # rules were installed. It means that all needed variables are set
 126 # by these rules directly so there's no need to acquire them again
 127 # later. Other rules can alternate the functionality based on this
 128 # fact (e.g. fallback to rules that behave correctly even without
 129 # these rules installed). It also provides versioning for any
 130 # possible future changes.
 131 # VSN 1 - original rules
 132 # VSN 2 - add support for synthesized events
 133 ENV{DM_UDEV_RULES_VSN}="2"
 134
 135 ENV{DM_UDEV_DISABLE_DM_RULES_FLAG}!="1", ENV{DM_NAME}=="?*", SYMLINK+="mapper/$env{DM_NAME}"
 136
 137 # Avoid processing and scanning a DM device in the other (foreign)
 138 # rules if it is in suspended state. However, we still keep 'disk'
 139 # and 'DM subsystem' related rules enabled in this case.
 140 ENV{DM_SUSPENDED}=="1", ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}="1"
 141
 142 GOTO="dm_end"
 143
 144 LABEL="dm_disable"
 145 ENV{DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG}="1"
 146 ENV{DM_UDEV_DISABLE_DISK_RULES_FLAG}="1"
 147 ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}="1"
 148 OPTIONS:="nowatch"
 149
 150 LABEL="dm_end"