From 966b1757143da1a0a826a4de02008264b1bacde3 Mon Sep 17 00:00:00 2001 From: Dan Nichilson Date: Wed, 12 Jul 2006 21:19:33 +0000 Subject: Various fixes and additions for examples of custom rules in Udev courtesy of Alexander Patrakov. Includes guidelines for persistent CD-ROM symlinks. git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@7661 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689 --- chapter07/chapter07.xml | 1 + chapter07/network.xml | 40 ++++++++++----- chapter07/symlinks.xml | 128 ++++++++++++++++++++++++++++++++++++++++++++++++ chapter07/udev.xml | 7 ++- 4 files changed, 160 insertions(+), 16 deletions(-) create mode 100644 chapter07/symlinks.xml (limited to 'chapter07') diff --git a/chapter07/chapter07.xml b/chapter07/chapter07.xml index c47adeb08..5f654f787 100644 --- a/chapter07/chapter07.xml +++ b/chapter07/chapter07.xml @@ -22,6 +22,7 @@ + diff --git a/chapter07/network.xml b/chapter07/network.xml index 8ae1399ca..884aeb94f 100644 --- a/chapter07/network.xml +++ b/chapter07/network.xml @@ -37,9 +37,10 @@ Realtek card becomes eth1. In some 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 - based on their MAC addresses. + based on their MAC addresses or bus positions. - First, find out the MAC addresses of your network cards: + If you are going to use MAC addresses to identify your network + cards, find the addresses with the following command: grep -H . /sys/class/net/*/address @@ -48,21 +49,36 @@ Udev rules similar to the following: cat > /etc/udev/rules.d/26-network.rules << "EOF" -ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="52:54:00:12:34:56", NAME="realtek" -ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="00:a0:c9:78:9a:bc", NAME="intel" +ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*", SYSFS{address}=="00:e0:4c:12:34:56", NAME="realtek" +ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*", SYSFS{address}=="00:a0:c9:78:9a:bc", NAME="intel" +EOF + + The DRIVER=="?*" key prevents Udev from attempting to rename 8021Q + VLAN interfaces (not available without the Vlan package from + ). + This is necessary since VLANs have the same MAC address as + the real network card. + + + + If you are going to use the bus position as a key, create + Udev rules similar to the following: + +cat > /etc/udev/rules.d/26-network.rules << "EOF" +ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:00:0c.0", NAME="realtek" +ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID=="0000:00:0d.0", NAME="intel" EOF These rules will always rename the network cards to - realtek and intel, independently of the - original numbering provided by the kernel. Use these names instead of - eth0 in the network interface configuration files created + realtek and intel, independently + of the original numbering provided by the kernel (i.e.: the original + eth0 and eth1 interfaces will no longer + exist, unless you put such descriptive names in the NAME + key). Use the descriptive names from the Udev rules instead + of eth0 in the network interface configuration files below. - - Persistent names must be different from the default network - interface names assigned by the kernel. - - diff --git a/chapter07/symlinks.xml b/chapter07/symlinks.xml new file mode 100644 index 000000000..c3e799867 --- /dev/null +++ b/chapter07/symlinks.xml @@ -0,0 +1,128 @@ + + + %general-entities; +]> + + + + + Creating custom symlinks to devices + + + + CD-ROM symlinks + + Some software that you may want to install later (e.g., various + media players) expect the /dev/cdrom and /dev/dvd symlinks to exist. + Also, it may be convenient to put references to those symlinks into + /etc/fstab. For each of your CD-ROM devices, + find the corresponding directory under + /sys (e.g., this can be + /sys/block/hdd) and + run a command similar to the following: + +udevtest /block/hdd + + Look at the lines containing the output of various *_id programs. + + There are two approaches to creating symlinks. The first one is to + use the model name and the serial number, the second one is based on the + location of the device on the bus. If you are going to use the first + approach, create a file similar to the following: + +cat >/etc/udev/rules.d/82-cdrom.rules <<"EOF" + +# Custom CD-ROM symlinks +SUBSYSTEM=="block", ENV{ID_MODEL}=="SAMSUNG_CD-ROM_SC-148F", ENV{ID_REVISION}=="PS05", SYMLINK+="cdrom" +SUBSYSTEM=="block", ENV{ID_MODEL}=="PHILIPS_CDD5301", ENV{ID_SERIAL}=="5VO1306DM00190", SYMLINK+="cdrom1 dvd" + +EOF + + This way, the symlinks will stay correct even if you move the drives + to different positions on the IDE bus, but the + /dev/cdrom symlink won't be created if you replace + the old SAMSUNG CD-ROM with a new drive. + + + The SUBSYSTEM=="block" key is needed in order to avoid + matching SCSI generic devices. Without it, in the case with SCSI + CD-ROMs, the symlinks will sometimes point to the correct + /dev/srX devices, and sometimes to + /dev/sgX, which is wrong. + + The second approach yields: + +cat >/etc/udev/rules.d/82-cdrom.rules <<"EOF" + +# Custom CD-ROM symlinks +SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", ENV{ID_PATH}=="pci-0000:00:07.1-ide-0:1", SYMLINK+="cdrom" +SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", ENV{ID_PATH}=="pci-0000:00:07.1-ide-1:1", SYMLINK+="cdrom1 dvd" + +EOF + + This way, the symlinks will stay correct even if you replace drives + with different models, but place them to the old positions on the IDE + bus. The ENV{ID_TYPE}=="cd" key makes sure that the symlink + disappears if you put something other than a CD-ROM in that position on + the bus. + + Of course, it is possible to mix the two approaches. + + + + + + Dealing with duplicate devices + + As explained in , the order in + which devices with the same function appear in + /dev is essentially random. + E.g., if you have a USB web camera and a TV tuner, sometimes + /dev/video0 refers to the camera and + /dev/video1 refers to the tuner, and sometimes + after a reboot the order changes to the opposite one. + For all classes of hardware except sound cards and network cards, this is + fixable by creating udev rules for custom persistent symlinks. + The case of network cards is covered separately in + , and sound card configuration can + be found in BLFS. + + For each of your devices that is likely to have this problem + (even if the problem doesn't exist in your current Linux distribution), + find the corresponding directory under + /sys/class or + /sys/block. + For video devices, this may be + /sys/class/video4linux/videoX. + Figure out the attributes that identify the device uniquely (usually, + vendor and product IDs and/or serial numbers work): + +udevinfo -a -p /sys/class/video4linux/video0 + + Then write rules that create the symlinks, e.g.: + +cat >/etc/udev/rules.d/83-duplicate_devs.rules <<"EOF" + +# Persistent symlinks for webcam and tuner +KERNEL=="video*", SYSFS{idProduct}=="1910", SYSFS{idVendor}=="0d81", SYMLINK+="webcam" +KERNEL=="video*", SYSFS{device}=="0x036f", SYSFS{vendor}=="0x109e", SYMLINK+="tvtuner" + +EOF + + The result is that /dev/video0 and + /dev/video1 devices still refer randomly to the tuner + and the web camera (and thus should never be used directly), but there are + symlinks /dev/tvtuner and + /dev/webcam that always point to the correct + device. + + More information on writing Udev rules can be found in + /usr/share/doc/udev-&udev-version;/index.html. + + + + diff --git a/chapter07/udev.xml b/chapter07/udev.xml index 50e66f759..a37e01732 100644 --- a/chapter07/udev.xml +++ b/chapter07/udev.xml @@ -267,8 +267,7 @@ This usually happens if a rule unexpectedly matches a device. For example, a poorly-writen rule can match both a SCSI disk (as desired) and the corresponding SCSI generic device (incorrectly) by vendor. - Increase the logging verbosity of Udev, find the offending rule by - examining the logs and make it more specific. + Find the offending rule and make it more specific. @@ -316,8 +315,8 @@ names being stable. Instead, create your own rules that make symlinks with stable names based on some stable attributes of the device, such as a serial number or the output of various *_id utilities installed by Udev. - See also the network interface renaming example in - . + See and + for examples. -- cgit v1.2.3-54-g00ecf