Bug#585015: kernel 2.6.34 fails to boot normally with mdadm > 3.1.1-1

[Neil Brown]

On Thu, 22 Jul 2010 12:36:47 +0200
Jean-Luc Coulon <jean-luc.coulon at wanadoo.fr> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Le 22/07/2010 10:16, Neil Brown a écrit :
> > 
> > On Thu, 22 Jul 2010 09:30:17 +0200
> > Jean-Luc Coulon <jean-luc.coulon at wanadoo.fr> wrote:
> 
> [ ... ]
> 
> > Debian doesn't add any significant patches to mainline mdadm, so you could 
> > 
> >   git clone git://neil.brown.name/mdadm
> >   cd mdadm
> > Then
> > 
> >   git bisect start mdadm-3.1.2 mdadm-3.1.1
> > 
> >   make ; make install ; mkinitramfs ; reboot
> >   git bisect good  OR git bisect bad
> > 
> > and see where you end up.
> > 
> > There are only 104 commits, so it should only take 7 iterations.
> 
> Ok, done, attached my log.

Great, thanks for doing that.

Had you run one more "git bisect good" it would have said:
319767b85c2b16d80c235195329470c46d4547b3 is the first bad commit
commit 319767b85c2b16d80c235195329470c46d4547b3
Author: NeilBrown <neilb at suse.de>
Date:   Mon Feb 8 14:33:31 2010 +1100

    mapfile: use ALT_RUN as alternate place to store mapfile
    
    This gives better consistency and fewer hidden '.' files.
    
    Signed-off-by: NeilBrown <neilb at suse.de>

:100644 100644 5444452df2914f3fc0b0fc128512d92e818e6627 366ebe332299c92fceaa4d3c9fa2e8c644b27801 M	mapfile.c

to make it explicit.
That patch changed the location where the mapfile is stored during initramfs
time from "/dev/.mdadm.map" to "/lib/init/rw/map".
Which:
  a/ isn't exactly what I wanted (I wanted /lib/init.rw/mdadm/map) and
  b/ doesn't exist - damn.
I thought that /lib/init/rw/map existed during early boot, but it seems not.
I guess I'm going to have to leave it in /dev - which I don't like at all but
there doesn't seem to be an option (OK Doug, you can say "I told you so" now).

Why that would cause infinite loops I'm not sure.  It would stop udev from
creating a symlink from /dev/md/whatever to /dev/mdXX - maybe that is enough
to upset some part of the boot process.

I wonder how that related to the kernel... you say it only breaks with 2.6.34.

I'll try experimenting with 2.6.34 and see if I can break it ... but not
today.
Meanwhile I'll revert that change for mdadm-3.1.3.

Thanks for your help.
NeilBrown