Package: debian-reference-en
Version: CVS HEAD
Severity: wishlist
Tags: patch

Section on nic interface naming is wrong for etch/udev.

See attached patch.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
--- gateway.sgml        2007-01-12 13:33:40.000000000 -0600
+++ gateway2.sgml       2007-08-29 14:22:12.000000000 -0500
@@ -1144,74 +1144,19 @@
 and should render ifupdown and friends obsolete.
 
 
-<sect id="high-rename">Dealing with inconsistent naming of interfaces by the 
kernel
+<sect id="high-rename">Dealing with the naming of interfaces
 <p>
-The names <tt>eth0</tt>, <tt>eth1</tt>, etc.
-are assigned by the kernel
-in the order that the kernel creates the interfaces
-that go by those names.
-While adapters that are detected at boot time
-are usually detected in the same order every time,
-and are therefore assigned the same names every time,
-the same is not true of adapters that are hot plugged.
-These can be detected in any order and end up getting
-assigned different names by the kernel
-on different occasions.
-<p>
-Because of this fact, on a system into which network adapters 
-are hot plugged it won't always do to define logical interfaces
-in <file>/etc/network/interfaces</file> with names
-<tt>eth0</tt>, <tt>eth1</tt>, etc., and to rely on the
-default mapping.
-Instead you must give distinct names to the logical interfaces
-and use one of the following two methods
-to restrict which logical interfaces can be assigned
-to which adapters.
-<p>
-This issue should be solved by using the current <package>udev</package> 
-package and its configuration.
-<!--
-One method is to use either
-the <prgn>nameif</prgn> utility
-(in the <package>net-tools</package> package)
-or the more flexible <prgn>ifrename</prgn> utility
-(in the <package>ifrename</package> package)
-to make the kernel assign names to interfaces
-according to properties of the underlying adapters.
-With this naming scheme in effect,
-the physical interface name can be used to infer
-which adapter underlies it.
-<p>
-Another method is to use <prgn>ifup</prgn>'s mapping mechanism
-in such a way that a logical interface is chosen
-for a physical interface being brought up
-according to some property of the adapter
-that underlies it.
-<p>
-Suppose, for example, you have two different network adapters
-which you use with networks <tt>net1</tt> and <tt>net2</tt>,
-respectively.
-The <file>/usr/share/doc/ifupdown/examples/</file> directory contains
-a mapping script that can be used to select a logical interface based
-on the Media Access Controller address (MAC address) of the adapter.
-First install the script to an appropriate directory.
-<example>
-# install -m770 /usr/share/doc/ifupdown/examples/get-mac-address.sh \
-   /usr/local/sbin/
-</example>
-Then add a stanza like the following to
-<file>/etc/network/interfaces</file>:
-<example>
-mapping eth0
-        script /usr/local/sbin/get-mac-address.sh
-        map 02:23:45:3C:45:3C net1
-        map 00:A3:03:63:26:93 net2
-</example>
-See <ref id="high-multistage-mapping"> for a more complex example.
-<p>
-In applying either method the property that is most commonly used
-to identify the adapter is the MAC address.
--->
+Udev remembers the mapping between network interface names and
+network interface MAC addresses.  It stores this information in
+the /etc/udev/rules.d/z25_persistent-net.rules file.  When, for example,
+replacing a network interface card the z25_persistent-net.rules file
+will need to be modified so that the name assigned to the discarded
+network card will be reused.
+<p>
+The kernel's inconsistent naming of interfaces should be solved by
+using the current <package>udev</package> 
+package and its configuration.  If udev is not used then interface
+names may not be assigned in a consistent manner, especially when hotplugged.
 
 <sect id="net-trigger">Triggering network configuration
 <p>

Reply via email to