Udev rule oddity

Bryan Kadzban bryan at kadzban.is-a-geek.net
Wed Jan 27 09:00:59 PST 2010

Matthew Burgess wrote:
> Matthew Burgess wrote:
>> Bryan Kadzban wrote:
>>> Or, actually, what happens if you move 70-persistent-net.rules 
>>> out to /dev/.udev/rules.d/, then do what we have in the 
>>> udev_retry bootscript? (That is, cat the file out of 
>>> /dev/.udev/rules.d, and append the result into /etc/udev/rules.d,
>>>  then rm the version in /dev/.udev/rules.d as a separate 
>>> operation.)  At what point is the message logged, if it's logged 
>>> in that operation anywhere?
>> The message gets logged as soon as I move 70-persistent* to 
>> /dev/.udev/rules.d.

OK; there's an inotify watch on that directory as well, so that still
could be it.

>>> If you have console access, you might also try booting with 
>>> init=/bin/bash (after deleting the generated rules) and running 
>>> each bootscript individually.  This should show which script is 
>>> causing the log message at least.  (Just be sure that if you get 
>>> to the point of mounting anything read-write, you unmount it 
>>> before rebooting.)
>> It's the S50udev_retry script that triggers it.

So it's either the cat, or the rm.  ...Probably the cat.

> And from a couple of test reboots it looks like the just-released 
> Udev-151 fixes it. Probably from this in the ChangeLog:
> udevd: inotify - do not parse rules at create but at close

Yeah, that would do it.  :-)

(I don't see a release announcement for -151 yet though.  Not that this
is relevant, just noting.)

Hmm.  It seems writing_udev_rules/index.html is now gone as well;
doesn't look like our current instructions will work anymore...  Ah:
"Delete outdated and unmaintained writing_udev_rules" (also from the

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20100127/6d85b211/attachment.sig>

More information about the lfs-dev mailing list