Am 10.10.2007 schrieb Marco d'Itri:
> On Oct 10, Anders Henke <[EMAIL PROTECTED]> wrote:
>
> > My suggestion is to enable/disable persistent net device naming via
> > some variable in a to-be-created /etc/default/udev, either globally
> > or for some specific device.
> rm /etc/udev/rules.d/z45_persistent-net-generator.rules
This link is automatically regenerated within the postinstall script:
if [ "$(dpkg --print-architecture)" != s390 ]; then
ln -s ../persistent-net-generator.rules
z45_persistent-net-generator.rules
fi
So the "just delete the link"-way of resolving this isn't really
friendly, as the problem is about to reappear after every udev update.
The link's name isn't also that easy to find, so this "solution" also
isn't that nice to the user.
E.g. after changing a box due to a failed on-board SCSI HBA,
the kernel (!) spews out warnings like this:
---cut
e1000: 0000:04:02.0: e1000_probe: (PCI-X:133MHz:64-bit)
00:30:48:2f:c1:54
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
Uniform watchdog device driver v0.01 loaded
iTCO_vendor_support: vendor-support=0
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10 (17-Aug-2007)
iTCO_wdt: Found a ICH5 or ICH5R TCO device (Version=1, TCOBASE=0x1060)
iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
eth0 renamed to eth2
sysfs: duplicate filename 'eth2' can not be created
WARNING: at fs/sysfs/dir.c:433 sysfs_add_one()
Call Trace:
[<ffffffff802b5183>] sysfs_add_one+0x54/0xbd
[<ffffffff802b5eba>] sysfs_create_link+0xc4/0x11e
[<ffffffff80360849>] device_rename+0x175/0x1d6
[<ffffffff803fdb6f>] dev_change_name+0x138/0x22c
[<ffffffff803fe3b1>] dev_ioctl+0x376/0x459
[<ffffffff8032f517>] __up_read+0x13/0x8a
[<ffffffff803f1615>] sock_ioctl+0x1e1/0x1ef
[<ffffffff80280cc9>] do_ioctl+0x21/0x6b
[<ffffffff80280f60>] vfs_ioctl+0x24d/0x266
[<ffffffff8027432d>] fd_install+0x25/0x59
[<ffffffff80280fb5>] sys_ioctl+0x3c/0x5f
[<ffffffff8020b55e>] system_call+0x7e/0x83
net eth2: device_rename: sysfs_create_symlink failed (-17)
e1000: 0000:04:02.1: e1000_probe: (PCI-X:133MHz:64-bit)
00:30:48:2f:c1:55
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
eth0 renamed to eth3
sysfs: duplicate filename 'eth3' can not be created
WARNING: at fs/sysfs/dir.c:433 sysfs_add_one()
[...]
---cut
It took me a while to find out who tried to rename my interfaces, provoked
kernel warnings and renamed interfaces just after changing a box's hardware;
main reason for this is that I didn't assume that udev tries to manage
devices who don't leave a footprint in /dev.
Personally, I think that it's a good idea to have consistent interface names,
but at least it's worth to take a note about this either during upgrading
from an older (pre-persistent-devicename) udev or non-udev box to a current
udev install or at least with a note in the README.Debian file, as this may
become a very significant change to the way the system works.
If the idea of persistent interface names is being used in a consistent
way (e.g. renaming network devices from eth0 to e.g. "lan" and making
users switch their configs to the new "lan" device), it's a cool way to
migrate between e.g. 2.4 and 2.6-based kernels (who enumerate e100/e1000
devices in a different way) or to work with hotpluggable network
interfaces (USB, PCMICA, ...).
However, there are clearly situations where the "old" behaviour is much
more appreciated, and I've given a few examples for this.
Regards,
Anders
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
