https://bugzilla.novell.com/show_bug.cgi?id=760859
https://bugzilla.novell.com/show_bug.cgi?id=760859#c28
Stefan Brüns changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |stefan.bruens@rwth-aachen.d
| |e
--- Comment #28 from Stefan Brüns 2012-11-19 23:14:21 UTC ---
I have another idea whats happening, and I found a workaround which works for
me:
Workaround:
--- /etc/init.d/boot.md 2012-06-05 13:29:11.000000000 +0200
+++ /tmp/boot.md 2012-11-20 00:02:42.281518551 +0100
@@ -123,6 +123,7 @@
# Wait for udev to settle
if [ "$MDADM_DEVICE_TIMEOUT" -gt 0 ] ; then
+ /sbin/udevadm trigger --verbose --subsystem-match=block
--attr-match=partition
/sbin/udevadm settle --timeout="$MDADM_DEVICE_TIMEOUT"
fi
(the --verbose is purely diagnostical)
Possible explanation:
the required udev-trigger (Should-Start ...) is run very early, before all
necessary devices are available. The settle then waits for an event queue which
does not contain the required devices.
I am not currently in reach of the affected machine, so I cannot debug it
myself, but this may be an approach:
1. in the udev-trigger.service, echo the current timestamp and the output of
"udev-adm trigger --dry-run --verbuse --attr-match=partition" to some log file.
2. in boot.md log the time stamp before the settle, and log the output of "
/sbin/udevadm settle --timeout=0 ; echo $?", which returns the current number
of outstanding events (to see if the settle is a noop)
3. in the udev md-raid rules, log the timestamp and device name of every "add"
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
