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>
Grow continue via service or fork is started during raid assembly.
If raid was assembled in initrd it will be newer restarted after
switch root.
Add udev support for starting mdadm-grow-continue service.
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@intel.com>
There is a bug in udev (which will hopefully get fixed, but
we should allow for it anways).
When reading a sysfs attribute, it first reads the whole
value of the attribute, then reads again expecting to get
a read of 0 bytes, like you would with an ordinary file.
If the sysfs attribute changed between these two reads, it can
get a mixture of two values.
In particular, if it reads when 'array_state' is changing from
'clear' to 'inactive', it can find the value as "clear\nve".
This causes the test for "|clear|active" to fail, so systemd is allowed
to think that the array is ready - when it isn't.
So change the pattern to allow for this but adding a wildcard at
the end.
Also don't allow for an empty string - reading array_state will
never return an empty string - if it exists at all, it will be
non-empty.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
When creating symlink of a md raid device, the detailed information of
component disks are unnecessary for rule udev-md-raid-arrays.rules. For
md raid devices with huge number of component disks (e.g. 1500 DASD
disks), the detail information of component devices can be very large
and exceed udev monitor's on-stack message buffer.
This patch adds '--no-devices' option when calling mdadm by,
IMPORT{program}="BINDIR/mdadm --detail --no-devices --export $devnode"
Now the detailed output won't include component disks information,
and the error message "invalid message length" reported by systemd can
be removed.
Signed-off-by: Coly Li <colyli@suse.de>
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
This rules will create link under /dev/disk/by-partuuid/ for
MD devices partition, with which will support specify
root=PARTUUID=XXX to boot rootfs.
Signed-off-by: Liwei Song <liwei.song@windriver.com>
Signed-off-by: Jes Sorensen <jsorensen@fb.com>
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>
1/ Add systemd shutdown script to ensure DDF and IMSM are
clean before we actually shutdown
2/ Get udev to tell systemd to run the mdmon@mdXXX.service
units when a member array appears.
If we boot off a member array (with dracut at least),
the mdmon started in the initramfs will lose track of
/sys etc, so we need to restart it.
systemd will try to forget about it too (but not actually
kill it because we said not to do this).
Having udev tell it to start it will allow a new mdmon to
run which can see /sys, and systemd will know about it.
3/ Always use --offroot and --takeover when starting mdmon with
systemd
--offroot is needed else shutdown will hang.
--takeover is needed incase an mdmon was started earlier
(e.g. in initramfs).
Neither hurt if they aren't actually needed.
Signed-off-by: NeilBrown <neilb@suse.de>
This systemd unit file runs mdadm in --monitor mode.
It is started by a SYSTEMD_WANTS signal from udev whenever
an md array is started that would benefit from mdadm --monitor.
Commandline arguments can be provided by a script
/usr/lib/systemd/scripts/mdadm_env.sh
which should write an
MDADM_MONITOR_ARGS=....
line to /run/sysconfig/mdadm
A script to extra args from SUSE's /etc/sysconfig/mdadm file
is provided.
If no mdadm_env.sh is provided, then args are "--scan" which
requires "mail" or "program" to be set in /etc/mdadm.conf.
I believe this is suitable for Fedora.
Signed-off-by: NeilBrown <neilb@suse.de>
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>
Mariusz Tkaczyk
Tkaczyk Mariusz
NeilBrown
Coly Li
Liwei Song
Thomas Bächler