From mboxrd@z Thu Jan 1 00:00:00 1970 From: DJ Lucas Date: Mon, 16 May 2011 05:05:56 +0000 Subject: Re: udevadm settle persistently failing Message-Id: <4DD0B0B4.2010508@lucasit.com> List-Id: References: <8739kfzv1j.fsf@spindle.srvr.nix> In-Reply-To: <8739kfzv1j.fsf@spindle.srvr.nix> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org On 05/15/2011 01:32 PM, Tom Gundersen wrote: > On Sun, May 15, 2011 at 8:19 PM, Nix 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=3Dsubsystems >> 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. > > Some related bug reports: > > Arch:, > Debian:. > > Cheers, > > Tom > -- > To unsubscribe from this list: send the line "unsubscribe linux-hotplug" = in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Just to add a "me too" regarding regular block devices. First noticed=20 with 168, coming from 165. /dev was tmpfs and swap is /dev/sda3 and=20 mounted immediately after udevadm --settle. Kernel is 2.6.36.2. In=20 addition to the udev change, I added the /run mount point to the mix=20 (started very early, directly in rc before any scripts are run). Moving=20 to devtmpfs 'fixed' it for me, but that was because devtmpfs has the raw=20 sd* nodes, as explained to me by another dev. If I flip to use by-id, it=20 breaks again. I plan to go back and see exactly where stuff broke, but=20 haven't had the time just yet, more pressing issues. Probably a=20 Wednesday evening project (CDT). -- DJ Lucas --=20 This message has been scanned for viruses and dangerous content, and is believed to be clean.