Bug#639830: mdadm: alternative md-device names

[Michael Tokarev]

[Back to the original bugreport, after removing all private data]

On 26.05.2012 16:06, Cristian Ionescu-Idbohrn wrote:
> On Sat, 26 May 2012, Michael Tokarev wrote:
>> On 26.05.2012 15:37, Cristian Ionescu-Idbohrn wrote:
>>> On Sat, 26 May 2012, Michael Tokarev wrote:
>>>> Do you still remember how did you fix it?
>>>
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639830#25
>>
>> This fix will not work once you upgrade mdadm package and
>> rebuild the initramfs, since the edits will be gone, replaced
>> by file from the new package.  So if that's the fix you rely
>> upon, it is very, well, fragile to say the best.  So you may
>> as well verify your system still boots if you revert that
>> change, -- verify when you can be prepared to handle a failure
>> instead of facing real failure again in a "wrong" moment.
> 
> As you probably can imagine, I'm not realy fond of that idea ;)

Don't worry, it all works...

>> Did you upgrade mdadm package past squeeze, -- it has been
>> updated in squeeze 6.0.3 IIRC.
> 
> Yes.
> hi  mdadm          3.2.5-1        tool to administer Linux MD arrays

..because it is sid, and this is mdadm version I uploaded to
unstable/sid just a few HOURS ago, and you already have it
installed.  This means you had a few upgrades of it already,
each overwrote your changes, and your system is still bootable.

In the initramfs/conf.d/md, only alternative device names are
listed, -- this also confirms that your change does not work
anymore, since after your change there should be both variants
of the naming.

> mdadm bug script output attached.

And now the whole thing looks pretty much okay, AND we can
be sure that at least the boot array is assembled automatically
from within initramfs, -- you still have your root filesystem
in /dev/md0 (or /dev/md/0).

Note the package is placed on hold, yet it is of very latest
unstable version.. you may want to inspect your system
configuration more closesly... ;)

Note also that you still have the same inconsistency -- you list
/dev/md/0 in mdadm.conf, but use /dev/md0 as root filesystem. I
can't say it works by design, more by a chance, it is better to
use consistent naming there.

As far as I can see, the original problem was due to the fact
that mdadm initramfs script did not assemble any arrays at all,
but it worked when using `mdadm --assemble --scan' manually.
That can happen if it weren't able to find running arrays to
start with, when generating initramfs.  The diffs from
update-initramfs you provided sort of confirm this.

But note this change:

commit debb4be5b5bdf2819699fd2a65e19632d98a1c5c
Author: martin f. krafft <madduck at debian.org>
Date:   Fri Jan 29 18:37:03 2010 +1300

    translate between /dev/mdX and /dev/md/X

    Signed-off-by: martin f. krafft <madduck at debian.org>

diff --git a/debian/changelog b/debian/changelog
index 6cd1eb8..a0e79bd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,7 @@ mdadm (3.1.1-2) UNRELEASED; urgency=low
     bugscript output.
   * Check active devices against configuration file based on UUID, not device
     name.
+  * When preparing the list of devices, treat /dev/mdX and /dev/md/X equally.

  -- martin f. krafft <madduck at debian.org>  Wed, 27 Jan 2010 14:42:16 +1300

diff --git a/debian/initramfs/hook b/debian/initramfs/hook
index 9b73055..b9c619a 100644
--- a/debian/initramfs/hook
+++ b/debian/initramfs/hook
@@ -195,6 +195,21 @@ else
         esac
       done
       [ -n "${dev:-}" ] || continue
+
+      # /dev/mdX and /dev/md/X are the same, really
+      case "$dev" in
+        (/dev/md/*) alt=/dev/md${dev##*/};;
+        (/dev/md*) alt=/dev/md/${dev#/dev/md};;
+        (*)
+          err "unknown device encountered: $dev"
+          warn_emergency
+          exit 0
+          ;;
+      esac
+      if [ ! -b "$dev" ] && [ -b "$alt" ]; then
+        dev="$alt"
+      fi
+
       echo -n "${dev}:"
       if [ -n "${level:-}" ]; then
         echo -n "$level"

(which has been made before reported version 3.1.4-1+8efb9d1)

This change should make the script to recgnize either form
when generating the image.  The only possible case I can think
of is when you listed

 INITRDSTART=/dev/md0

(the same as for root filesystem in fstab), but using /dev/md/0
in mdadm.conf -- in this case, mkinitramfs reports:

W: mdadm: I am supposed to start /dev/md0 from the initial ramdisk,
W: mdadm: yet I cannot find the array in the configuration file.
W: mdadm: I am thus reverting to starting all arrays.

But actually it does not start anything during initramfs, in the
way you observed.

Is (was) that the case, can you remember/comment ?

Thanks,

/mjt