gronod/lfs
1
0
Fork 0
mirror of https://git.linuxfromscratch.org/lfs.git synced 2025-06-19 03:39:20 +01:00
Code Issues Packages Projects Releases Wiki Activity

Use upstream Udev rule_generator setup for NIC naming; fixes #1912. Also fix a validation error in r7923.

Browse Source 
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@7924 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Bryan Kadzban 2007-02-18 00:40:32 +00:00
parent 84dbfdac1d
commit 80640a4990
3 changed files with 62 additions and 111 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
chapter01/changelog.xml
View File

@ -39,6 +39,11 @@
<listitem> <listitem>
<para>2007-02-17</para> <para>2007-02-17</para>
<itemizedlist> <itemizedlist>
<listitem>
<para>[bryan] - Use upstream's rule_generator rules exclusively for
NIC naming, and generate the rules before configuring the network
script, so the user knows what NIC names to use.</para>
</listitem>
<listitem> <listitem>
<para>[bryan] - Change from writing CD symlink rules files directly <para>[bryan] - Change from writing CD symlink rules files directly
to configuring the file installed by Udev's rule_generator. Fixes to configuring the file installed by Udev's rule_generator. Fixes

157
chapter07/network.xml
View File

@ -26,9 +26,6 @@
<sect2> <sect2>
<title>Creating stable names for network interfaces</title> <title>Creating stable names for network interfaces</title>
<para>Instructions in this section are optional if you have only one
network card.</para>
<para>With Udev and modular network drivers, the network interface numbering <para>With Udev and modular network drivers, the network interface numbering
is not persistent across reboots by default, because the drivers are loaded is not persistent across reboots by default, because the drivers are loaded
in parallel and, thus, in random order. For example, on a computer having in parallel and, thus, in random order. For example, on a computer having
@ -36,116 +33,64 @@
by Intel may become <filename class="devicefile">eth0</filename> and the by Intel may become <filename class="devicefile">eth0</filename> and the
Realtek card becomes <filename class="devicefile">eth1</filename>. In some Realtek card becomes <filename class="devicefile">eth1</filename>. In some
cases, after a reboot the cards get renumbered the other way around. To cases, after a reboot the cards get renumbered the other way around. To
avoid this, create Udev rules that assign stable names to network cards avoid this, Udev comes with a script and some rules to assign stable names
based on their MAC addresses or bus positions.</para> to network cards based on their MAC address.</para>
<para>If you are going to use MAC addresses to identify your network <para>Pre-generate the rules to ensure the same names get assigned to the
cards, find the addresses with the following command:</para> same devices at every boot, including the first:</para>
<screen role="nodump"><userinput>grep -H . /sys/class/net/*/address</userinput></screen> <screen><userinput>/lib/udev/write_net_rules all_interfaces</userinput></screen>
<para>For each network card (but not for the loopback interface), <para>Now, inspect the <filename>/etc/udev/rules.d/70-persistent-net.rules</filename>
invent a descriptive name, such as <quote>realtek</quote>, and create file, to find out which name was assigned to which network device:</para>
Udev rules similar to the following:</para>
<screen role="nodump"><userinput>cat &gt; /etc/udev/rules.d/70-persistent-net.rules &lt;&lt; EOF <screen><userinput>cat /etc/udev/rules.d/70-persistent-net.rules</userinput></screen>
<literal>ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="<replaceable>00:e0:4c:12:34:56</replaceable>", \
NAME="<replaceable>realtek</replaceable>"
ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="<replaceable>00:a0:c9:78:9a:bc</replaceable>", \
NAME="<replaceable>intel</replaceable>"</literal>
EOF</userinput></screen>
<!-- Yes, I know that VLANs are beyond BLFS. This is not the reason to get them <para>Each NIC takes up two lines in the file. The first line is a
incorrect by default when every distro does this right. --> description of the NIC itself, showing its hardware IDs (e.g. its PCI
vendor and device IDs, if it's a PCI card), along with its driver in
parentheses, if the driver can be found. This line is a comment; neither
the hardware ID nor the driver is used to determine which name to give an
interface. The second line is the Udev rule that matches this NIC and
actually assigns it a name.</para>
<note> <para>All Udev rules are made up of several keys, separated by commas and
<para>Be aware that Udev does not recognize the backslash for line optional whitespace. This rule's keys and an explanations of each of them
continuation. The examples in this book work properly because both are as follows:</para>
the backslash and newline are ignored by the shell. This makes the
shell send each rule to cat on only one line. (The shell ignores
this sequence because the EOF string used in the here-document
redirection is not enclosed in either double or single quotes. For
more details, see the bash(1) manpage, and search it for "Here
Documents".)</para>
<para>If modifying Udev rules with an editor, be sure to leave each
rule on one physical line.</para>
</note>
<para>If you are going to use the bus position as the key, find the <itemizedlist>
position of each card with the following commands:</para> <listitem>
<para><literal>SUBSYSTEM=="net"</literal> - This tells Udev to ignore
<screen role="nodump"><userinput>for dir in /sys/class/net/* ; do devices that are not network cards.</para>
[ -e $dir/device ] &amp;&amp; { </listitem>
basename $dir ; readlink -f $dir/device <listitem>
} <para><literal>DRIVERS=="?*"</literal> - This exists so that Udev will
done</userinput></screen> ignore VLAN or bridge sub-interfaces (because these sub-interfaces do
not have drivers). These sub-interfaces are skipped because the name
<para>This will yield output similar to:</para> that would be assigned would collide with their parent devices.</para>
</listitem>
<screen role="nodump"><userinput><replaceable>eth0</replaceable> <listitem>
/sys/devices/pci0000:00/<replaceable>0000:00:0c.0</replaceable> <para><literal>ATTRS{type}=="1"</literal> - Optional. This key will
<replaceable>eth1</replaceable> only be added if this NIC is a wireless NIC whose driver creates
/sys/devices/pci0000:00/<replaceable>0000:00:0d.0</replaceable></userinput></screen> multiple virtual interfaces; it ensures the rule only matches the
primary interface. The secondary interfaces are not matched for the
<para>In this example, <replaceable>eth0</replaceable> has PCI bus position same reason that VLAN and bridge sub-interfaces are not matched: there
<replaceable>0000:00:0c.0</replaceable> (domain 0000, bus 00, device 0c, would be a name collision.</para>
function 0), and <replaceable>eth1</replaceable> has PCI bus position </listitem>
<replaceable>0000:00:0d.0</replaceable> (domain 0000, bus 00, device 0d, <listitem>
function 0).</para> <para><literal>ATTRS{address}</literal> - The value of this key is the
NIC's MAC address.</para>
<para>Now create Udev rules similar to the following:</para> </listitem>
<listitem>
<screen role="nodump"><userinput>cat &gt; /etc/udev/rules.d/70-persistent-net.rules &lt;&lt; EOF <para><literal>NAME</literal> - The value of this key is the name that
<literal>ACTION=="add", SUBSYSTEM=="net", BUS=="<replaceable>pci</replaceable>", KERNELS=="<replaceable>0000:00:0c.0</replaceable>", \ Udev will assign to this interface.</para>
NAME="<replaceable>realtek</replaceable>" </listitem>
ACTION=="add", SUBSYSTEM=="net", BUS=="<replaceable>pci</replaceable>", KERNELS=="<replaceable>0000:00:0d.0</replaceable>", \ </itemizedlist>
NAME="<replaceable>intel</replaceable>"</literal>
EOF</userinput></screen> <para>The value of <literal>NAME</literal> is the important part. Make sure
you know which name has been assigned to each of your network cards before
<para>Udev has installed a rule_generator rules file that uses MAC proceeding, and be sure to use that <literal>NAME</literal> value when
addresses, not bus positions. Rules generated by this file will conflict creating your configuration files below.</para>
with the rules you just created, so delete the file:</para>
<screen role="nodump"><userinput>rm /etc/udev/rules.d/75-persistent-net-generator.rules</userinput></screen>
<note>
<para>You will also have to remember to create a new bus-position-based
rule each time you plug in an additional network card. In a MAC address
based persistence scheme, the rule_generator rules file would do this
automatically.</para>
</note>
<para>Regardless of which method you use, these rules will always rename
the network cards to <quote>realtek</quote> and <quote>intel</quote>,
independently of the original numbering provided by the kernel (i.e.: the
original <quote>eth0</quote> and <quote>eth1</quote> interfaces will no
longer exist, unless you put such <quote>descriptive</quote> names in the
NAME key). Use the descriptive names from the Udev rules instead of
<quote>eth0</quote> in the network interface configuration files
below.</para>
<para>Note that the rules above don't work for every setup. For example,
MAC-based rules break when bridges or VLANs are used, because bridges and
VLANs have the same MAC address as the network card. One wants to rename
only the network card interface, not the bridge or VLAN interface, but the
example rule matches both. If you use such virtual interfaces, you have two
potential solutions. One is to add the DRIVER=="?*" key after
SUBSYSTEM=="net" in MAC-based rules which will stop matching the virtual
interfaces. This is known to fail with some older Ethernet cards because
they don't have the DRIVER variable in the uevent and thus the rule does
not match with such cards. Another solution is to switch to rules that use
the bus position as a key.</para>
<para>The second known non-working case is with wireless cards using the
MadWifi or HostAP drivers, because they create at least two interfaces with
the same MAC address and bus position. For example, the Madwifi driver
creates both an athX and a wifiX interface where X is a digit. To
differentiate these interfaces, add an appropriate KERNEL parameter such as
KERNEL=="ath*" after SUBSYSTEM=="net".</para>
<para>There may be other cases where the rules above don't work. Currently,
bugs on this topic are still being reported to Linux distributions, and no
solution that covers every case is available.</para>
</sect2> </sect2>

11
chapter07/symlinks.xml
View File

@ -49,11 +49,12 @@
<!-- If you use by-id mode, the symlinks will survive even the transition <!-- If you use by-id mode, the symlinks will survive even the transition
to libata for IDE drives, but that is not for the book. --> to libata for IDE drives, but that is not for the book. -->
<important>External devices (for example, a USB-connected CD drive) should <important><para>External devices (for example, a USB-connected CD drive)
not use by-path persistence, because each time the device is plugged into a should not use by-path persistence, because each time the device is plugged
new external port, its physical path will change. All externally-connected into a new external port, its physical path will change. All
devices will have this problem if you write Udev rules to recognize them externally-connected devices will have this problem if you write Udev rules
by their physical path; the problem is not limited to CD and DVD drives.</important> to recognize them by their physical path; the problem is not limited to CD
and DVD drives.</para></important>
<para>If you wish to see the values that the Udev scripts will use, then <para>If you wish to see the values that the Udev scripts will use, then
for the appropriate CD-ROM device, find the corresponding directory under for the appropriate CD-ROM device, find the corresponding directory under