70-persistent-net.rules not created

jmscott at setex.ipcallback.com jmscott at setex.ipcallback.com
Tue Jan 12 06:33:57 PST 2010

On Mon, Jan 11, 2010 at 01:08:35AM -0600, Bruce Dubbs wrote:
> jmscott at setex.ipcallback.com wrote:
> > On Sun, Jan 10, 2010 at 10:37:13PM -0600, Bruce Dubbs wrote:
> >> jmscott at setex.ipcallback.com wrote:
> >>
> >>> the standard output to /lib/udev/write_net_rules is 
> >>> caught and filtered by udevadm, so examining the env list to execve()
> >>> seemed a bit more direct.
> >> Where is standard output caught?  I don't see it. After options, udevadm 
> > 
> > libudev/libudev-util-private.c, util_run_program(), line 238.
> > 
> > from a causual reading of the source, looks like 
> > udevadm-test() eventually calls util_run_program() 
> We may be running different versions of udev.  I'm looking at 145.
> > getting late ... i'm sure it's something simple.
> > mere matter of debugging.
> I agree.  I haven't heard of anyone else having the problem.

i apologize for truncating the full conversation.

regarding the following code blurb in LFS 6.5, chapter 7.13.1

     for NIC in /sys/class/net/* ; do
         INTERFACE=${NIC##*/} udevadm test --action=add $NIC

i've come to the conclusion that something is missing.

as best i can tell, the environment variable INTERFACE is not passed unqualified
to the dependent script /lib/udev/write_net_rules referenced in the rules file
/lib/udev/rules.d/75-persistent-net-generator.rules, causing the error 

    util_run_program: '/lib/udev/write_net_rules' (stderr) 'missing $INTERFACE'

so far, my opinion is that either a rule to export INTERFACE needs to be 
added to some rules file, which escapes me now, or this is just flat out a bug.

so, in the name of progress, i like to solict advice on what to do next,
before my hacking corrupts the still unbooted lfs filesystem.
since i have only one eth0 nic, is it safe to simply ignore the generation
of /etc/udev/rules.d/70-persistent-net.rules and move on to chapter 8?
won't the single nic be installed as eth0, anyway.

again, my apologies for not including the entire conversation.


More information about the lfs-support mailing list