Bug#639830: mdadm: alternative md-device names

[Cristian Ionescu-Idbohrn]

On Sat, 26 May 2012, Michael Tokarev wrote:
> On 26.05.2012 16:06, Cristian Ionescu-Idbohrn wrote:
> > 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.

True.  All that stuff vanished when I replaced the discs.

> 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).

Yes.

> 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... ;)

Yes.  The package is placed on hold, intentionally.

> 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.

Alright.  You possibly mean changing /etc/fstab?  Is /dev/md/0 the
preferred device name (and /dev/md0 an alias) or the other way around?

> 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.

Sounds like that was the case.

> 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)

Well, as I said, I don't recall much about the circumstances but it would
seem the problems I had were related to:

	* When preparing the list of devices, treat /dev/mdX and /dev/md/X equally.

in one way or another.

> 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

Many moons later, but yes, it sounds reasonable.

> (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.

Yes, I do recall those messages ;)

> But actually it does not start anything during initramfs, in the
> way you observed.
>
> Is (was) that the case, can you remember/comment ?

Sorry.  Parts of my memory were wiped out at some point ;)
Maybe the bug#632401 submitter can remember more?


Cheers,

-- 
Cristian