Bug#844652: mdadm 3.4-4's new initramfs script location broke my system boot

[Marc MERLIN]

Package: mdadm
Version: 3.4-4

Howdy,

The old mdadm had scripts/local-top/mdadm
Due to maybe random lucky ordering, it was being run on my system before
local-top/cryptroot

My system's rootfs is an raid1 which used to be detected by the kernel
a long time ago, but that's been deprecated and does not work anymore.
Now it relies on an mdadm command for it to show up and work.
Without it showing up, cryptroot does not have a partition it can mount
from and everything falls over
I boot with:
root=/dev/mapper/cryptroot ro rootflags=subvol=root cryptopts=source=/dev/md13,keyscript=/sbin/cryptgetpw

Anyway, it's been working fine for years, until I upgraded mdadm and it
all broke because mdadm moved its initramfs init script to run much
later (too late) in the initramfs process (local-block/mdadm):

> Begin: Mounting root file system ... Begin: Running /scripts/local-top ...   Reading all physical volumes.  This may take a while...
> Begin: Waiting for encrypted source device... ...   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
> (...)
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
> done.
>   ALERT! /dev/md13 does not exist.
>         Check cryptopts=source= bootarg: cat /proc/cmdline
>         or missing modules, devices: cat /proc/modules; ls /dev
> -r Dropping to a shell. Will skip /dev/md13 if you can't fix.
> Rebooting automatically due to panic= boot argument
> done.

To recover, I had to manually copy the old scripts/local-top/mdadm from
the old mdadm package, and copy it in 
/usr/share/initramfs-tools/scripts/local-top/a_mdadm

This also sadly cost me quite a bit of unexpected downtime and 4 to 6H
of slow debugging since I thought my problem was due to a new kernel and
in fact it was simply that any new initrd created was unable to boot
because of an mdadm upgrade, and not due to the kernel (my old kernels
had an old generated initrd that still worked).

Now, I still seem to rely on pseudo random ordering to run mdadm before 
cryptroot but I'm not sure the mdadm package is able to stick itself as
prereq of the cryptroot script...

Either way, this upgrade broke me and may brake others.
I realize the whole thing is not trivial. What do you think is the
right fix foreveryone?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/