execute to generate /etc/udev/rules.d/70-persi
/lib/udev/write_net_rules all_interfaces
or reinstall udev
Main Topics
Browse All TopicsOut of old habit I deleted this file, thinking it would get recreated upon reboot like it did on Etch.
well.. The file didn't get recreated and my network is not working after booting unless I modprobe the driver first.
I probably shouldn't have deleted that file, but since I've done it too many times on Etch I didn't think it would be problematic.
I've tried running udevadm trigger and I've also tried adding the driver module to /etc/modules, but networking isn't coming up automatically.
I know I could setup modprobe to load during boot by adding a statement to rc.local, but I would really like to get it working the "proper" way of having that udev-file generated again.
Lars
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
lubo,
"As of version 0.090, udev has the ability to statically rename ethernet cards based on MAC address. The addresses are configured in /etc/udev/rules.d/z25_pers
sh0e
If I run that command I get the message "missing $INTERFACE".
Lars
ls -lart /dev/.udev
rm -rf /dev/.udev/.lock-*
rm /dev/.udev/tmp-rules*
re-trigger events
If there are still problems,
Did this problem occur before?
If not, were there any particular software changes/upgrades before this?
It would seem that udev is not able to detect/load properly. Please check this to verify:
ls -lart /sys/class/net/
# ls -lart /dev/.udev
total 4
drwxr-xr-x 2 root root 60 2008-09-04 10:18 rules.d
drwxr-xr-x 2 root root 260 2008-09-04 10:18 failed
drwxr-xr-x 170 root root 3400 2008-09-04 10:19 names
drwxr-xr-x 2 root root 2960 2008-09-04 10:19 db
drwxr-xr-x 11 root root 3240 2008-09-04 10:19 ..
-rw-r--r-- 1 root root 4 2008-09-04 10:27 uevent_seqnum
drwxr-xr-x 6 root root 140 2008-09-04 10:27 .
re-trigger what? reinstall udev?
The reason I deleted this file was because if you change a nic in debian 4.0 you can delete this file (well... z25) and upon reboot the new nic info will be generated in the file again. I expected debian 5.0 to behave similar, but obviously something has changed.
# ls -lart /sys/class/net/
total 0
drwxr-xr-x 4 root root 0 2008-09-04 10:17 lo
drwxr-xr-x 30 root root 0 2008-09-04 10:18 ..
drwxr-xr-x 4 root root 0 2008-09-04 10:19 .
drwxr-xr-x 4 root root 0 2008-09-04 10:19 eth0
Sorry for the long wait. I've been away.
FYI There is an update on Lenny, udev 0.125-6
udevinfo -a -p /sys/class/net/eth0
udevadm control --log_priority=debug
echo add > /sys/class/net/eth0/uevent
Yes, 75-persistent-net-generato
Was networking working before 70-persistent-net.rules was deleted?
Put this into 70-persistent-net.rules replacing 00:00:00:00:00:00 with the MAC address:
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:00:
Yes, networking was working before I deleted this file. I deleted this file because I wanted to create a Lenny template that can be easily cloned to a new system without too much hassle. I've done this since debian 3.0 and it allows for a quick way of having a debian ready with my preferred packages ready to go on a new system (normally a virtual machine). Since Etch I've had to delete this file for networking to work automatically. I'm also generating new ssh keys and setting a new hostname in this process.
I recreated that file now and replaced the mac address, but only after a modprobe I could get networking working again, but my main goal was to avoid having such a system specific file.
Lars
The persistent rules are not necessary for networking to work. You can just delete 75-persistent-net-generato
Are you testing this on VMware?
There is a known issue related to VMware tools that was fixed just a day or two ago. Not sure if the fix was committed yet though (very doubtful). The package in question is open-vm-tools
To verify, ls -l /etc/init.d/open-vm-tools
In any case, update udev to the latest version.
And try to update open-vm-tools. You may need to get the package out of sid (unstable).
If I am incorrect, are the outputs you've given before you modprobe? Can you show me the output of lsmod before and after?
Business Accounts
Answer for Membership
by: LuxanaPosted on 2008-09-02 at 16:27:59ID: 22372676
Hi larstr,
istent-net -generator .rules
istent-net .rules with line and your MAC address: DDRESS", NAME="eth0"
/
Did you by any chance removed some other files from /etc/udev/rules.d/ ? I have lenny installed and z25_persistent-net.rules gets re-created every time, same as it did with etch.
There is one file which takes care of the creation of this file so make sure its there:
/etc/udev/rules.d/z45_pers
Also I must admit I do not know what is 70-persistent-net.rules because on the etch as well as on lenny it should be file z25_persistent-net.rules by default, but I may be wrong :-)
try create file /etc/udev/rules.d/z25_pers
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="YOUR:MAC:A
if that does not pick p the driver replace ?* with your module for your NIC and try again.
hope this helps
lubo
http://www.linuxconfig.org