Recent Features
| |||||||||||||
Char devices for network interfacesChar devices for network interfacesPosted Oct 15, 2009 2:03 UTC (Thu) by marineam (subscriber, #28387)Parent article: Char devices for network interfaces
udev has handled persistent names (even automatically!) based on MAC address for ages... I even had to submit a patch to disable the behavior on Xen because the ethX name was getting incremented by 1 every time the VM rebooted and got a new randomly assigned MAC address. :-P
Is everyone using distros that like to disable this feature or something?
(Log in to post comments)
Char devices for network interfaces Posted Oct 15, 2009 4:14 UTC (Thu) by gdt (subscriber, #6284) [Link] You can't assume the MAC address remains the same before and after a repair. Sysadmins curse every time a faulty mainboard is replaced and then the operating system fails to come up properly. Read Matt's mail, it's a good summary of the current suckiness of network interface name enumeration. Although even it misses some classics, such as some Intel motherboards being marked NIC1 and NIC2 and getting eth1 and eth0 respectively assigned to those interfaces, despite DMI being correct.
Char devices for network interfaces Posted Oct 15, 2009 6:28 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
I am currently removing udev from my server systems entirely (in large part due to this issue)
prior to this I had manually removed the entry in the udev config that had it deal with network devices.
while I understand the theory (you don't want a device to change names and send traffic out the wrong interface), this feature has always caused me significant amounts of trouble, and I've never once had it save me (I manage several hundred firewalls, so in theory I would be the prime beneficiary of this feature)
Char devices for network interfaces Posted Oct 15, 2009 12:47 UTC (Thu) by nix (subscriber, #2304) [Link]
Er, you can tell udev to keep its hands off your network interfaces by simply removing the network generator rules. There's no need to ditch the whole thing.
Char devices for network interfaces Posted Oct 15, 2009 17:46 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
yes, and I did that for a while, but then an update to udev added it back in.
Char devices for network interfaces Posted Oct 15, 2009 18:54 UTC (Thu) by nix (subscriber, #2304) [Link]
This of course is the downside of having this sort of thing in a set
of 'standard rules': it's hard to eliminate them without hacking udev before installation :/
Char devices for network interfaces Posted Oct 15, 2009 19:07 UTC (Thu) by joey (subscriber, #328) [Link]
Removing rules files would work fine if a) using dpkg and b) udev had left
its rules files as conffiles under /etc. This sort of situation is why dpkg does not add back deleted conffiles on upgrade. But since udev's rules files have moved to /lib/udev, deletion of rules files will no longer persist across upgrades.
Now it seems you'd have to create an empty version of the net generator rule
Rather a mess.
Char devices for network interfaces Posted Oct 15, 2009 20:09 UTC (Thu) by nix (subscriber, #2304) [Link]
That was exactly my moan :)
I'm not sure that creating an empty version of the net generator rule file
> It does not matter in which directory a rule file lives, all files are
which could go either way.
Char devices for network interfaces Posted Oct 16, 2009 3:02 UTC (Fri) by njs (guest, #40338) [Link]
dpkg-divert --add --local /lib/udev/rules.d/75-persistent-net-generator.rules --divert /lib/udev/die-die-die --rename ?
The use of /lib here does seem bizarre though.
Char devices for network interfaces Posted Oct 16, 2009 16:15 UTC (Fri) by nix (subscriber, #2304) [Link]
Well, /lib/udev was already in use for other udev stuff which has to be runnable before /usr is mounted (e.g. /lib/udev/vol_id).
But, yes, putting what damn well should be conffiles (as witness the fact that people want to change them, even if udev upstream is resistant) in /lib is demented.
Char devices for network interfaces Posted Oct 22, 2009 18:18 UTC (Thu) by jengelh (subscriber, #33263) [Link]
You are supposed to truncate the file, not remove it. It's the only way the SHA check will work as intended, presuming that the udev files are also marked as %config(noreplace) in rpm.
Char devices for network interfaces Posted Oct 16, 2009 3:21 UTC (Fri) by pjones (guest, #31722) [Link]
That doesn't really address the problem - when you boot the installer the first time, udev is basically randomly picking which one is which. This means that any setup an IT department needs to do elsewhere in the network relating to, for example, which port is which, can't be done until after installation - which may be too late.
|
|||||||||||||