summaryrefslogtreecommitdiffstats
path: root/udev-md-raid-assembly.rules (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Incremental: support devnode in IncrementalRemove.Mariusz Tkaczyk2024-09-101-2/+2
| | | | | | | | There are no reasons to keep this interface different than others. Allow to use devnode but keep old way for backward compatibility. Method is added to verify that only devnode or kernel name is used. Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
* mdadm/udev: Don't handle change event on raw devicesXiao Ni2023-01-051-0/+8
| | | | | | | | | | | | | | | | | | | The raw devices are ready when add event happpens and the raid can be assembled. So there is no need to handle change events. And it can cause some inconvenient problems. For example, the OS is installed on md0(/root) and md1(/home). md0 and md1 are created on partitions. When it wants to re-install OS, anaconda can't clear the storage configure. It deletes one partition and does some jobs. The change event happens. Now the raid device is assembled again. It can't delete the other partitions. So in this patch, we don't handle change event on raw devices anymore. Signed-off-by: Xiao Ni <xni@redhat.com> Signed-off-by: Jes Sorensen <jes@trained-monkey.org>
* udev: adapt rules to systemd v247Mariusz Tkaczyk2022-03-311-2/+3
| | | | | | | | | | | | | | New events have been added in kernel 4.14 ("bind" and "unbind"). Systemd maintainer suggests to modify "add|change" branches. This patches implements their suggestions. There is no issue yet because new event types are not used in md. Please see systemd announcement for details[1]. [1] https://lists.freedesktop.org/archives/systemd-devel/2020-November/045646.html Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
* udev: Ignore change event for imsmMariusz Tkaczyk2020-04-271-1/+1
| | | | | | | | | | | | | When adding a device to a container mdadm has to close its file descriptor before sysfs_add_disk(). This generates change event. There is race possibility because metadata is already written and other -I process can place drive differently. As a result device can be added to two containers simultaneously. From IMSM perspective there is no need to react for change event. IMSM doesn't support stacked devices. Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@intel.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
* Use correct syntax for passing DEVLINKS to mdadm from udevNeilBrown2017-08-161-1/+1
| | | | | | | | | | | | ${DEVLINKS} is not valid udev syntax, and is passed through uninterpreted. $env{DEVLINKS} or %e{DEVLINKS} is correct. Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
* udev-md-raid-assembly.rules: Skip non-ready devicesHannes Reinecke2017-03-281-0/+3
| | | | | | | | | | | | | | | If a device isn't fully initialized (e.g if it should be handled by multipathing) it should not be considered for md/RAID auto-assembly. Doing so can cause incorrect results such as causing multipath to fail during startup. There is a convention that the udev environment variable SYSTEMD_READY be set to zero for such devices. So change the mdadm rules to ignore devices with SYSTEMD_READY==0. Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
* install: use BINDIR consistently to locate mdadm and mdmonNeilBrown2014-05-221-3/+3
| | | | | | | | Every place where the paths for mdadm or mdmon is explicit, it should use the BINDIR setting, not "/sbin/". Reported-by: member graysky <graysky@archlinux.us> (https://bugs.archlinux.org/task/37330) Signed-off-by: NeilBrown <neilb@suse.de>
* udev rules: try "mdadm -I" on "change" events.NeilBrown2013-12-111-2/+2
| | | | | | | | | | | | We need to attempt "mdadm -I" on "change" events as well as "add" events, as the "change" make make a device ready to be part of an array. This is particularly important for stacked md devices. When the member devices are "add"ed they don't have any content visible yet. That doesn't happen until a "change". Idea taken from Fedora udev file. Signed-off-by: NeilBrown <neilb@suse.de>
* udev rules: add some by-pass rules from FedoraNeilBrown2013-12-111-1/+16
| | | | | | | | 1/ If ANACONDA is running, don't -I assemble any arrays, ANACONDA needs to be in control 2/ honour "noiswmd" and "nodmraid" kernel command line options. Signed-off-by: NeilBrown <neilb@suse.de>
* Incremental: improve support for "DEVICE" based restriction in mdadm.confNeilBrown2013-12-031-1/+1
| | | | | | | | | | | | | | | | | --incremental currently fails if the device name passed does not textually match the names permitted by the DEVICE line in mdadm.conf. This is problematic when "mdadm -I" is run by udev as the name given can be a temp name. This patch makes two improvements: 1/ We generate a list of all existing devices that match the names in mdadm.conf, and allow rdev based matching 2/ We allows extra aliases to be provided on the command line, and perform textual matching on those. This is particularly suitable for udev usages as ${DEVLINKS} can be provided even though the links make not yet be created. Signed-off-by: NeilBrown <neilb@suse.de>
* Systemd integration for starting newly-degraded arrays.NeilBrown2013-12-021-1/+2
| | | | | | | | | | | | | | | | Normally "mdadm -I" will not start an array if it has reason to expect further devices. This means that if a device is removed while the host is shut down, "mdadm -I" will never start the device. If the array is know to the host, it make sense to start the array anyway after a reasonable timeout. This patch adds systemd/udev infrastructure so that 30 seconds after a known array first becomes able to be assembled as a degraded array, the array will be assembled even if more devices are still expected. Signed-off-by: NeilBrown <neilb@suse.de>
* udev: Fix order of execution of the md rulesThomas Bächler2013-02-111-0/+19
Right now, the rules that run blkid on raid arrays are executed after the assembly rules. This means incremental assembly will always fail when raid arrays are again physical components of raid arrays. Instead of simply reversing the order, split the rules up into two files, one dealing with array properties and one dealing with assembly. Signed-off-by: NeilBrown <neilb@suse.de>