On Sun, May 15, 2011 at 20:32, Tom Gundersen <teg@xxxxxxx> wrote: > On Sun, May 15, 2011 at 8:19 PM, Nix <nix@xxxxxxxxxxxxx> wrote: >> I know that you're not supposed to rely on 'udevadm settle' anymore, but >> I rely on it across the board for systems with root filesystems that >> aren't expected to move around (i.e. all of them), because massively >> reengineering working systems' boot processes is generally considered a >> bad thing. And it's stopped working. Given how many things expect /dev >> to be populated, this has fairly serious effects. >> >> I can be certain that as of somewhere between udev 164 and 167, 'udevadm >> settle' has stopped waiting for block devices to appear (though I >> suspect others have vanished too). I'm booting udev as recommended in >> the release notes, via >> >> Âudevd --daemon >> Âudevadm trigger --action=add --type=subsystems >> Âudevadm trigger --action=add --type=devices >> Âudevadm settle > > We are doing the same on Arch and today I started seeing bug reports > (after the upgrade to udev 168). So here are my two cents: > > Most of the time the problem seems to be related to LVM, but I have > also seen regular block devices having problems. As would be expected > using devtmpfs greatly reduces (if not eliminates) the problem. My > guess was (like Nix said) that "udevadm settle" is somehow broken. We are sure it's not related to /run? We keep the state there and need a tmpfs there before udevd is started, and it must not be touched, or cleaned by some other stuff, that thinks /var/run (bind mount or symlink) needs to be cleaned during boot. Devtmpfs solves a lot of settle races, yeah. We should run fine on tmpfs, but it's the only config that is really tested these days, so it might be a problem nobody else is really seeing. The current settle wakes up in exactly the moment the last event is gone, instead of it sleep()ing in a loop. It might be a bit earlier, not really before stuff has settled though. Does this work for you? time (udevadm trigger; udevadm settle) It should not return immediately. You can watch the events with: udevadm monitor at the same time and check if it really only returns after the last event. Kay -- 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
