On Wed, 25 Feb 2026 21:33:23 +0100
tito via Dng <dng@???> wrote:

> On Wed, 25 Feb 2026 15:50:49 +0000
> Rainer Weikusat via Dng <dng@???> wrote:
>
> > tito <farmatito@???> writes:
> > > On Tue, 24 Feb 2026 20:39:35 +0000 Rainer Weikusat via Dng <dng@???> wrote:
> > >> In case this is of interest to someone: I've created a fork of the
> > >> Devuan unstable mdadm package which can be built on daedalus. This has
> > >> mdadm version 4.5 which is
> >
> > [...]
> >
> > > Hi,
> > > thanks for your effort, one minor bug that hit me
> > > just yesterday after migrating a nas box from daedalus
> > > to excalibur with mdadm/stable,now 4.4-11devuan3
> > > was a daily email with this message that was harmless
> > > but alarming.
> > >
> > > mdadm: DeviceDisappeared event detected on md device /dev/md/md0
> > > mdadm: NewArray event detected on md device /dev/md0
> >
> > [...]
> >
> > > cat /etc/udev/rules.d/md0.rules
> > > # Work around an array detection bug in mdmonitor
> > > SUBSYSTEM=="block", ACTION=="add|change", ENV{MD_UUID}=="705d30b8:1b64bf1b:8d5bf391:65e26d6f", SYMLINK+="md/%k"
> >
> > As far as I could determine, such symlinks are created automatically by
> > 63-md-raid-arrays.rules. The 4.2-5 version of the package (daedalus)
> > should do this as well.
>
> Hi,
>
> in my case apparently this was not triggered even after rebooting the system
> cannot say why. Only after adding the rule and running udevadm trigger
> the symlink was created and DeviceDisappeared messages stoppped.
> Have no Idea how this could be debugged tough. Let me know
> if you have any ideas. Can do some tests on this machine even tough
> it is a production one.
>
> Ciao,
> Tito

P.s.: I suspect mdadm expects /dev/md/mdX when run as mdadm --monitor --scan --oneshot (by e.g. cron)
but creates a mdadm.conf with /dev/md0 when run as mdadm --detail --scan

ARRAY /dev/md0 metadata=1.2 spares=1 UUID=705d30b8:1b64bf1b:8d5bf391:65e26d6f

even when /dev/md/md0 symlinks are already created.