>> >> Trying to figure something out here, using the following I'm seeing a >> delay in the creation of block devices in /dev ... >> >> # trigger the sorted events >> echo -e '\000\000\000\000'> /proc/sys/kernel/hotplug >> >> rm -fr /dev/.udev> /dev/null 2>&1 >> mkdir -p /dev/.udev> /dev/null 2>&1 >> /sbin/udevd >> >> # Not entirely sure what this is for >> /sbin/udevadm control --env=STARTUP=1 >> /sbin/udevadm trigger > >> /sbin/udevadm settle > > settle should have waited until all events have been processed Does this mean fully processed or just received? I asked on #udev/irc.freenode.net and was told that settle only waits until udev had received them. The only reason it worked before was because of the speed improvements made recently. >> # Nor sure what this does >> /sbin/udevadm control --env=STARTUP= >> >> >> I think my problem is, while all the events have been sent to udevd >> there is a delay if I do a "fsck LABEL=root" straight on say the next >> line, a "ls" shows that none of the block devices exist until a second >> or two later. A sleep 5 before my "ls" works around this and the block >> devices show up. >> >> Any ideas how I can determine once all udev events have finished >> processing so I can continue boot? > > check would look like: > /sbin/udevadm settle --timeout=0 || echo "Still not all udev events > processed" > > waiting should be: > /sbin/udevadm settle Same result on both. I went further and wrote a small C app to wait for the udev event, this works 100%. I run the C app in the background before I run trigger & settle, then do a "wait" until it returns. -N -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
