Matthew Burgess wrote: > I wasn't sure whether to report this as a bug in LFS or Udev or > whether it's just my misunderstanding. If I remove > /etc/udev/rules.d/70-persistent* (simulating how things look on a > first boot into a freshly-built system) I then get the following on a > reboot: > > udevd[371]: can not read '/etc/udev/rules.d/70-persistent-cd.rules' > udevd[371]: can not read '/etc/udev/rules.d/70-persistent-net.rules'
This smells like inotify acting unexpectedly. Looking at write_net_rules, the actual rules are generated by lots of individual calls to echo. If inotify wakes up udev after -- say -- the first echo finishes (and appends to the empty file), it's *possible* that udev will read a blank file. What I don't know is whether this causes it to log that error. Can you create an empty (say) 99-test.rules file in /etc/udev/rules.d and see if it logs the same thing? I believe it'll write to /dev/kmsg, so the log message should show up in the kernel logs, if it gets sent... 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? > By the time I've logged in, those files do exist because they were > created by write_cd_rules and write_net_rules respectively, in turn > by 75-cd-aliases-generator.rules and > 75-persistent-net-generator.rules. > > So the question is, why does Udev try to read files that don't exist > yet? How does it even know that they will/should exist? This looks > to me to be some kind of race condition but I'm not overly sure! Yeah, seems like a race to me as well. Otherwise udev would have had to hardcode the 70-persistent-*.rules filenames somewhere, to know to try to look for them. 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.)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
