|Summary:||sys-fs/udev-104-r10 persistent net problems when adding new NIC|
|Product:||Gentoo Linux||Reporter:||Matthias Schwarzott <zzam>|
|Component:||New packages||Assignee:||udev maintainers <udev-bugs>|
|Package list:||Runtime testing required:||---|
Description Matthias Schwarzott 2007-02-12 11:31:48 UTC
Adding new NIC gives these network devices: eth0, eth1_rename. Reproduce: 1. Having a system with one or more NICs. 2. They are correct listed in /etc/udev/rules.d/70-persistent-net.rules as eth0 (eth1, eth2, ...). 3. Adding new NIC to the system. 3. Boot. 4. udev takes 30sec more. 5. you get devices: eth0 eth1_rename 6. The tmp-rules file (/dev/.udev/tmp-rules--70-persistent-net.rules) contains a rule for the new device, but as name for new device it has one which was already given to another NIC in normal rules file.
Comment 1 Matthias Schwarzott 2007-02-12 12:07:20 UTC
Rebooting will not solve the problem, as at reboot-time the tmp-rule file is also getiing saved to normal location. That means every boot udev will take its 30sec more, and leave at least one eth?_rename interface. Solutions: 1. delete rule-files: rm /etc/udev/rules.d/70-persistent-net.rules rm /dev/.udev/tmp-rules--70-persistent-net.rules 2. Edit rule file(s) to contain unique device names.
Comment 2 Matthias Schwarzott 2007-02-12 13:32:42 UTC
Bug is caused by this: code to look for already used device-names tests the rules file for existance before getting its info out of there. So far so good. But in our case (root-fs still read-only) it only checks tmp-location /dev/.udev/tmp-rules--... which for sure is not existing at that point. Thus device-logic can accept already used device, and udev rename logic fight with two or more interfaces to get that name. Fixed in udev-104-r11 by just deleting that check - sed can cope with non-existing files, will only print a warning (that gets redirected to /dev/null by udev).