The wait_for_udev patch cannot possibly fix the original problem, of
md devices not starting because their components are slow to come up,
because the wait_for_udev only happens *after* the attempt to assemble
md devices. If you change nothing else, there's still only a single
attempt at assembly, liable to happen before slow components come online.
I have run into exactly the same problem as the original reporter. I am
now using the patch below. It adds a crude delay/retry loop to the md
assembly process, for the case where INITRDSTART lists devices explicitly.
(The "all" case would be considerably more complicated, unless one
were to translate it into an explicit list by reading mdadm.conf.)
Note that most assembly attempts are made with --no-degraded; this is
in case some components become available before others. Only when the
retry limit is reached will a degraded assembly be accepted.
The delay/retry arrangement could be made much more sophisticated.
My version uses a fixed number of retries with relatively large delays.
A nicer arrangement would be to retry more rapidly until a configurable
amount of time has passed. Also, assembly of all the desired md devices
could be attempted in parallel, so that if everything is coming up
degraded the retry delay is only incurred once.
PATCH
--- /usr/share/initramfs-tools/scripts/local-top/mdadm 2013-01-24
13:26:51.000000000 +0000
+++ /etc/initramfs-tools/scripts/local-top/mdadm 2013-07-22
21:31:57.038274846 +0000
@@ -87,7 +87,20 @@
for dev in $MD_DEVS; do
verbose && log_begin_msg "Assembling MD array $dev"
- if $MDADM --assemble --scan --run --auto=yes $dev; then
+ devok=false
+ for try in 0 1 2 3 4; do
+ if $MDADM --assemble --scan --no-degraded --auto=yes $dev; then
+ devok=true
+ break
+ fi
+ sleep 2
+ done
+ if ! $devok; then
+ if $MDADM --assemble --scan --run --auto=yes $dev; then
+ devok=true
+ fi
+ fi
+ if $devok; then
verbose && log_success_msg "started $dev"
else
log_failure_msg "failed to start $dev"
PATCH
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
