70-persistent-net.rules not created

jmscott at setex.ipcallback.com jmscott at setex.ipcallback.com
Mon Jan 11 06:16:23 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.

bb4a557de1fcef2cbeefea8b8e7cb7938bb54760  udev-145.tar.bz2
7091aa1ec78fdb9247f3813d785bc4e9a03efd2b  udev-config-20090523.tar.bz2

> > getting late ... i'm sure it's something simple.
> > mere matter of debugging.

from a casual reading of the udevadm source, to me it appears the construction
of the envp list to execve() is anything but simple.  so far,
the udev source i'm examining is consistent with the behavior i'm seeing,
but i haven't hacked too deeply, since i'm trying to keep the lfs fs 
as pristine as possible.

it appears only execve() invokes the script, so the environment would be
created explicitly.  i don't see any reference to the global **environ list
or to any environment passed in main(), so i assume the environment
is derived according some interaction with the rules file.

before hacking too much further, i ought to readup on udevadm.
unfortunately, my linux kernel building knowledge is way pre udev.

> I agree.  I haven't heard of anyone else having the problem.
>    -- Bruce

hi-ho, hi-ho ...


> -- 
> http://linuxfromscratch.org/mailman/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/lfs/faq.html
> Unsubscribe: See the above information page

More information about the lfs-support mailing list