On Sun, 2009-02-01 at 21:52 -0500, Stefan Monnier wrote: > > Here's another guess: > > Your USB rootfs is not quite in sync for your firmware rootfs.
Most definitely true. > So the > firmware rootfs starts udev (aka hotplug2) and doesn't kill it before > doing pivot_root, and your USB rootfs doesn't kill it either, so you > end up woith 2 hotplug2 daemons running Ahhh. You might be on to something: r...@gw:~# ps -ef | grep hotplug 207 root 1132 S /sbin/hotplug2 --no-coldplug --persistent --set-rules 366 root 1128 S /sbin/hotplug2 --override --persistent --max-children But I would expect the pre-pivot_root hotplug2 to show it's root as being where the old root was pivoted to, which is /oldroot, however it doesn't: r...@gw:~# ls -l /proc/207/root lrwxrwxrwx 1 root root 0 Feb 2 18:47 /proc/207/root -> / r...@gw:~# ls -l /proc/366/root lrwxrwxrwx 1 root root 0 Feb 2 18:47 /proc/366/root -> / > and your firmware-load > request is handled by the first hotplug2 which lives in the firmware's > rootfs where b43/b0g0initvals5.fw is indeed absent. Maybe this is the case. > A "recent" change to the way hotplug2 is started&killed around > pivot_root made me bump into the exact above scenario. How did you solve it? Even if you give me command line actions just to test your theory out, I'd be happy to. Thanx! b.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
