Bug#675452: mdadm: initramfs script race condition between loading modules and assembling arrays

[Michael Tokarev]

Control: tag -1 + moreinfo

01.06.2012 14:11, Alastair Irvine (Warpspace IT) wrote:
> Package: mdadm
> Version: 3.1.4-1+8efb9d1+squeeze1
> Severity: important
> 
> /usr/share/initramfs-tools/scripts/local-top/mdadm does not wait after
> loading modules in the "Loading MD modules" step.  Therefore, when it
> does the "Assembling all MD arrays" step the relevant modules might not
> have created the /dev/md* nodes yet.
> 
> I have seen this happen on a live system:
> 1) raid modules are loaded
> 2) array assembly is attempted
> 3) assembly fails
> 4) drops to busybox prompt
> 5) kernel message appears showing discovery of md0 etc.
> 
> This issue cannot be solved by the rootdelay kernel parameter since the
> issue relates to actions taken solely within the initramfs script.
> 
> /usr/share/initramfs-tools/scripts/local-top/mdadm has not been changed
> between squeeze and wheezy.

This bugreport is a bit confusing and confused several people as well.
I merged it with another bug (#714155) but I think it is not right,
unless I'm confused again.  Unmerging it now.

It _looks_ like this bug is about stacked raid arrays, and a race
between assembling lower-level devices and assembling higher-level
devices.  So that once we assembled lower-level device we immediately
jump to assembling higher-level devices which depends on the just
assembled lower-level, but this lower-level isn't ready yet.

Am I right?

But from the provided mdadm.conf I don't see it is the case, because:

> /etc/mdadm/mdadm.conf:
> # definitions of existing MD arrays
> ARRAY /dev/md0 level=raid1 num-devices=2 UUID=b36f0bd4:cab828a7:5992f6ac:53538ad0
> ARRAY /dev/md1 level=raid1 num-devices=2 UUID=0dca4f37:f7ca8a5d:6063584c:84c0bcc1
> ARRAY /dev/md2 level=raid1 num-devices=2 UUID=0e5ea519:39088dae:f48fc6bd:56a6866b
> ARRAY /dev/md3 level=raid5 num-devices=4 UUID=29333179:958cbe2e:e69bb13b:b2322f99

because I don't see arrays which can possible be stacked.  Maybe raid5 md3
is built out of md[012] and something else not listed in there, but this makes
no sense really.

There's one more possible race, but I don't really think it exists:
a race between loading modules and trying to use them, as the subject
line tells us.  Loading modules does NOT create /dev/md* devices, only
assembling arrays does that.  And I think these days, and that's for
quite some time already, mdadm will work fine without any md-related
modules loaded, with kernel loading modules on demand.

So, I'm not really sure what's going on here.

Tagging as 'moreinfo' for now.  But since this bugreport is 2.5 years
old now I don't have much hope anymore to know the actual problem... :(

Thanks,

/mjt