История изменений
Исправление manul91, (текущая версия) :
Как все это работает разъяснено например тут:
https://utcc.utoronto.ca/~cks/space/blog/linux/SoftwareRaidAssemblySystemd
Посмотрел на bullseye сервак который древнее (и там все точно работает).
Оказывается этот механизм - все эти юниты (и соответно udev script который запускает таймеры) имеют место еще с bullseye:
root@virtgurunew:~# systemctl status mdadm-last-resort@md0.service
● mdadm-last-resort@md0.service - Activate md array md0 even though degraded
     Loaded: loaded (/lib/systemd/system/mdadm-last-resort@.service; static)
     Active: inactive (dead)
       Docs: man:mdadm(8)
root@virtgurunew:~# systemctl cat mdadm-last-resort@md0.service
# /lib/systemd/system/mdadm-last-resort@.service
[Unit]
Description=Activate md array %I even though degraded
DefaultDependencies=no
ConditionPathExists=!/sys/devices/virtual/block/%i/md/sync_action
Documentation=man:mdadm(8)
[Service]
Type=oneshot
ExecStart=/sbin/mdadm --run /dev/%i
root@virtgurunew:~# 
root@virtgurunew:~# systemctl status mdadm-last-resort@md0.timer
● mdadm-last-resort@md0.timer - Timer to wait for more drives before activating degraded array md0.
     Loaded: loaded (/lib/systemd/system/mdadm-last-resort@.timer; static)
     Active: inactive (dead)
    Trigger: n/a
   Triggers: ● mdadm-last-resort@md0.service
root@virtgurunew:~# ll /usr/lib/systemd/system/mdadm*
-rw-r--r-- 1 root root 508 Feb  9  2021 /usr/lib/systemd/system/mdadm-grow-continue@.service
-rw-r--r-- 1 root root 237 Feb  9  2021 /usr/lib/systemd/system/mdadm-last-resort@.service
-rw-r--r-- 1 root root 179 Feb  9  2021 /usr/lib/systemd/system/mdadm-last-resort@.timer
lrwxrwxrwx 1 root root   9 Feb  9  2021 /usr/lib/systemd/system/mdadm.service -> /dev/null
-rw-r--r-- 1 root root 723 Feb  9  2021 /usr/lib/systemd/system/mdadm-shutdown.service
lrwxrwxrwx 1 root root   9 Feb  9  2021 /usr/lib/systemd/system/mdadm-waitidle.service -> /dev/null
root@virtgurunew:~# 
root@virtgurunew:~# 
root@virtgurunew:~# 
root@virtgurunew:~# cat /usr/lib/udev/rules.d/64-md-raid-assembly.rules 
# do not edit this file, it will be overwritten on update
# Don't process any events if anaconda is running as anaconda brings up
# raid devices manually
ENV{ANACONDA}=="?*", GOTO="md_inc_end"
# assemble md arrays
SUBSYSTEM!="block", GOTO="md_inc_end"
# skip non-initialized devices
ENV{SYSTEMD_READY}=="0", GOTO="md_inc_end"
# handle potential components of arrays (the ones supported by md)
ENV{ID_FS_TYPE}=="linux_raid_member", GOTO="md_inc"
# "noiswmd" on kernel command line stops mdadm from handling
#  "isw" (aka IMSM - Intel RAID).
# "nodmraid" on kernel command line stops mdadm from handling
#  "isw" or "ddf".
IMPORT{cmdline}="noiswmd"
IMPORT{cmdline}="nodmraid"
ENV{nodmraid}=="?*", GOTO="md_inc_end"
ENV{ID_FS_TYPE}=="ddf_raid_member", GOTO="md_inc"
ENV{noiswmd}=="?*", GOTO="md_inc_end"
ENV{ID_FS_TYPE}=="isw_raid_member", GOTO="md_inc"
GOTO="md_inc_end"
LABEL="md_inc"
# remember you can limit what gets auto/incrementally assembled by
# mdadm.conf(5)'s 'AUTO' and selectively whitelist using 'ARRAY'
ACTION=="add|change", IMPORT{program}="/sbin/mdadm --incremental --export $devnode --offroot $env{DEVLINKS}"
ACTION=="add|change", ENV{MD_STARTED}=="*unsafe*", ENV{MD_FOREIGN}=="no", ENV{SYSTEMD_WANTS}+="mdadm-last-resort@$env{MD_DEVICE}.timer"
ACTION=="remove", ENV{ID_PATH}=="?*", RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}"
ACTION=="remove", ENV{ID_PATH}!="?*", RUN+="/sbin/mdadm -If $name"
LABEL="md_inc_end"
root@virtgurunew:~# hostnamectl
   Static hostname: virtgurunew
         Icon name: computer-server
           Chassis: server
        Machine ID: 80c196e4211844b6804a5810875c1f2b
           Boot ID: 3cb05a3ed9754bdf89cf95870cccdb19
  Operating System: Debian GNU/Linux 11 (bullseye)
            Kernel: Linux 5.10.0-33-amd64
      Architecture: x86-64
root@virtgurunew:~# 
Интересно что mdadm-last-resort юниты и таймеры работают в bullseye без ручной инсталяции, прямо из /lib/systemd/system/mdadm-last-resort@.service (udevd rule запускает таймер)
Но ведь то же самое по дефолту было и в trixie/forky.
Поэтому, что именно сломалось в trixie / forky - по-прежнему не понятно.
Факт, что если в trixie/forky юниты/таймеры проинсталлировать явно чтобы всегда запускались - кустарным способом как я выше сделал - то все начинает работать (хотя теперь думаю нет ли здесь опасность для какой-то race, хотя и в юнитов есть соответный кондишн).
Смотрел правило udev в forky сравнивал с bullseye - вобщем все выглядит аналогично, непонятно почему в forky/trixie не работает. Может регресия какая-то в недрах udev или systemd.
Исходная версия manul91, :
Как все это работает разъяснено например тут:
https://utcc.utoronto.ca/~cks/space/blog/linux/SoftwareRaidAssemblySystemd
Посмотрел на bullseye сервак который древнее (и там все точно работает).
Оказывается этот механизм - все эти юниты (и соответно udev script который запускает таймеры) имеют место еще с bullseye:
root@virtgurunew:~# systemctl status mdadm-last-resort@md0.service
● mdadm-last-resort@md0.service - Activate md array md0 even though degraded
     Loaded: loaded (/lib/systemd/system/mdadm-last-resort@.service; static)
     Active: inactive (dead)
       Docs: man:mdadm(8)
root@virtgurunew:~# systemctl cat mdadm-last-resort@md0.service
# /lib/systemd/system/mdadm-last-resort@.service
[Unit]
Description=Activate md array %I even though degraded
DefaultDependencies=no
ConditionPathExists=!/sys/devices/virtual/block/%i/md/sync_action
Documentation=man:mdadm(8)
[Service]
Type=oneshot
ExecStart=/sbin/mdadm --run /dev/%i
root@virtgurunew:~# 
root@virtgurunew:~# systemctl status mdadm-last-resort@md0.timer
● mdadm-last-resort@md0.timer - Timer to wait for more drives before activating degraded array md0.
     Loaded: loaded (/lib/systemd/system/mdadm-last-resort@.timer; static)
     Active: inactive (dead)
    Trigger: n/a
   Triggers: ● mdadm-last-resort@md0.service
root@virtgurunew:~# ll /usr/lib/systemd/system/mdadm*
-rw-r--r-- 1 root root 508 Feb  9  2021 /usr/lib/systemd/system/mdadm-grow-continue@.service
-rw-r--r-- 1 root root 237 Feb  9  2021 /usr/lib/systemd/system/mdadm-last-resort@.service
-rw-r--r-- 1 root root 179 Feb  9  2021 /usr/lib/systemd/system/mdadm-last-resort@.timer
lrwxrwxrwx 1 root root   9 Feb  9  2021 /usr/lib/systemd/system/mdadm.service -> /dev/null
-rw-r--r-- 1 root root 723 Feb  9  2021 /usr/lib/systemd/system/mdadm-shutdown.service
lrwxrwxrwx 1 root root   9 Feb  9  2021 /usr/lib/systemd/system/mdadm-waitidle.service -> /dev/null
root@virtgurunew:~# 
root@virtgurunew:~# 
root@virtgurunew:~# 
root@virtgurunew:~# cat /usr/lib/udev/rules.d/64-md-raid-assembly.rules 
# do not edit this file, it will be overwritten on update
# Don't process any events if anaconda is running as anaconda brings up
# raid devices manually
ENV{ANACONDA}=="?*", GOTO="md_inc_end"
# assemble md arrays
SUBSYSTEM!="block", GOTO="md_inc_end"
# skip non-initialized devices
ENV{SYSTEMD_READY}=="0", GOTO="md_inc_end"
# handle potential components of arrays (the ones supported by md)
ENV{ID_FS_TYPE}=="linux_raid_member", GOTO="md_inc"
# "noiswmd" on kernel command line stops mdadm from handling
#  "isw" (aka IMSM - Intel RAID).
# "nodmraid" on kernel command line stops mdadm from handling
#  "isw" or "ddf".
IMPORT{cmdline}="noiswmd"
IMPORT{cmdline}="nodmraid"
ENV{nodmraid}=="?*", GOTO="md_inc_end"
ENV{ID_FS_TYPE}=="ddf_raid_member", GOTO="md_inc"
ENV{noiswmd}=="?*", GOTO="md_inc_end"
ENV{ID_FS_TYPE}=="isw_raid_member", GOTO="md_inc"
GOTO="md_inc_end"
LABEL="md_inc"
# remember you can limit what gets auto/incrementally assembled by
# mdadm.conf(5)'s 'AUTO' and selectively whitelist using 'ARRAY'
ACTION=="add|change", IMPORT{program}="/sbin/mdadm --incremental --export $devnode --offroot $env{DEVLINKS}"
ACTION=="add|change", ENV{MD_STARTED}=="*unsafe*", ENV{MD_FOREIGN}=="no", ENV{SYSTEMD_WANTS}+="mdadm-last-resort@$env{MD_DEVICE}.timer"
ACTION=="remove", ENV{ID_PATH}=="?*", RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}"
ACTION=="remove", ENV{ID_PATH}!="?*", RUN+="/sbin/mdadm -If $name"
LABEL="md_inc_end"
root@virtgurunew:~# hostnamectl
   Static hostname: virtgurunew
         Icon name: computer-server
           Chassis: server
        Machine ID: 80c196e4211844b6804a5810875c1f2b
           Boot ID: 3cb05a3ed9754bdf89cf95870cccdb19
  Operating System: Debian GNU/Linux 11 (bullseye)
            Kernel: Linux 5.10.0-33-amd64
      Architecture: x86-64
root@virtgurunew:~# 
Интересно что mdadm-last-resort юниты и таймеры работают в bullseye без ручной инсталяции, прямо из /lib/systemd/system/mdadm-last-resort@.service (udevd rule запускает таймер)
Поэтому, что именно сломалось в trixie / forky - по-прежнему не понятно.
Факт, что если в trixie/forky юниты/таймеры проинсталлировать явно чтобы всегда запускались - кустарным способом как я выше сделал - то все начинает работать (хотя теперь думаю нет ли здесь опасность для какой-то race, хотя и в юнитов есть соответный кондишн).
Смотрел правило udev в forky сравнивал с bullseye - вобщем все выглядит аналогично, непонятно почему в forky/trixie не работает. Может регресия какая-то в недрах udev или systemd.