On Apr 6, 2013 7:32 PM, <kwk...@hkbn.net> wrote: > > On Sat, 6 Apr 2013 19:11:46 +0700 > Pandu Poluan <pa...@poluan.info> wrote: > > > On Apr 6, 2013 3:44 PM, "Neil Bothwick" <n...@digimed.co.uk> wrote: > > > > > > On Fri, 5 Apr 2013 21:14:39 -0400, Walter Dnes wrote: > > > > > > > * on a machine with multiple network cards *ALL USING DIFFERENT > > > > DRIVERS* > > > > * drivers are built as modules, not built-in into the kernel > > > > * is it possible to set things up so that the network driver > > > > modules do not load automatically at bootup? > > > > * have a script in /etc/local.d/ (or wherever) modprobe the > > > > drivers in the desired order > > > > > > > > I can see complications involving services that depend on net > > > > (e.g. sshd), but in general, would it work reliably? > > > > > > What happens if one of the modules fails to load for any reason? > > > > > > If you need persistent device names, set up rules to give them, but > > > use names outside of the kernel namespace to avoid kk problems that > > > udev is trying to avoid with its new naming rules.ooh > > > > > > > Ahhh... I think now I understand... > > > > So. Here's my summarization of the situation: > > > > * The ethX naming can change, i.e., the interfaces can get out of > > order > > * So, to fix this, udev decided to use the physical attachment points > > of the NIC in driving a persistent name, a name that will be > > identical across boots as long as there is no hardware change > > There are also other ways such as using the mac address (disabled by > default). > > > * In doing so, it also frees the 'traditional' ethX names to be used > > No. The eth[0-9]+ namespace is not free, it has always been used by > the linux kernel, and will stay so. > > > * If one wants, one can still 'rename' the NICs to the 'traditional' > > names using the 70-*.rules script > > * Doing so (specifying the NICs' names using the 70-*r.rules script) > > will also disable the new 'persistent naming' system -- for the NICs > > specified in the 70-*r.rules file > > * Therefore, users that will be impacted are those that upgraded udev > > but doesn't have the 70-*r.rules, for udev will then assign new names > > for the NICs > > * For these users, specifying the net....something switch for the > > kernel (sorry, forgot the complete switch) will disable the new > > naming system > > > > So, have I gotten everything correctly? > > Almost, except you should not specify a name that is also eth[0-9]+ > (what you called 'traditional' name), since it can cause a race > condition where the kernel and udev fight for the name. While it used > to be the case (i.e. <udev-197) that udev tries to handle the race > condition, the devs has decided to remove those code. > > Regards, > > Kerwin.
Ah, thanks for the clarification! :-) So, from now on, for safety I'm going to use a custom naming scheme, like lan[0-9]+ or wan[0-9]+ or wifi[0-9]+, anything that won't collide with kernel names of eth[0-9]+ Now I only had to figure out how to rename eth[0-9]+ to the custom naming scheme when using mdev. Rgds, --
