#: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:11 msgid "Managing Devices" msgstr "" #. type: Content of: <sect1><sect2><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:15 msgid "Network Devices" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:17 msgid "" "Udev, by default, names network devices according to Firmware/BIOS data or " "physical characteristics like the bus, slot, or MAC address. The purpose of " "this naming convention is to ensure that network devices are named " "consistently and not based on the time the network card was discovered. For " "example, on a computer having two network cards made by Intel and Realtek, " "the network card manufactured by Intel may become eth0 and the Realtek card " "becomes eth1. In some cases, after a reboot the cards could get renumbered " "the other way around." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:26 msgid "" "In the new naming scheme, typical network device names would then be " "something like enp5s0 or wlp3s0. If this naming convention is not desired, " "the traditional naming scheme or a custom scheme can be implemented." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:32 msgid "Disabling Persistent Naming on the Kernel Command Line" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:34 msgid "" "The traditional naming scheme using eth0, eth1, etc can be restored by " "adding <userinput>net.ifnames=0</userinput> on the kernel command line. " "This is most appropriate for those systems that have only one ethernet " "device of the same type. Laptops often have multiple ethernet connections " "that are named eth0 and wlan0 and are also candidates for this method. The " "command line is passed in the GRUB configuration file. See <xref " "linkend=\"grub-cfg\"/>." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:45 msgid "Creating Custom Udev Rules" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:47 msgid "" "The naming scheme can be customized by creating custom udev rules. A script " "has been included that generates the initial rules. Generate these rules by " "running:" msgstr "" #. type: Content of: <sect1><sect2><sect3><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:51 #, no-wrap msgid "<userinput>bash /lib/udev/init-net-rules.sh</userinput>" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:53 msgid "" "Now, inspect the " "<filename>/etc/udev/rules.d/70-persistent-net.rules</filename> file, to find " "out which name was assigned to which network device:" msgstr "" #. type: Content of: <sect1><sect2><sect3><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:57 #, no-wrap msgid "<userinput>cat /etc/udev/rules.d/70-persistent-net.rules</userinput>" msgstr "" #. type: Content of: <sect1><sect2><sect3><note><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:59 msgid "" "In some cases such as when MAC addresses have been assigned to a network " "card manually or in a virtual environment such as Qemu or Xen, the network " "rules file may not have been generated because addresses are not " "consistently assigned. In these cases, this method cannot be used." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:65 msgid "" "The file begins with a comment block followed by two lines for each NIC. The " "first line for each NIC is a commented description 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. Neither the hardware ID " "nor the driver is used to determine which name to give an interface; this " "information is only for reference. The second line is the udev rule that " "matches this NIC and actually assigns it a name." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:73 msgid "" "All udev rules are made up of several keys, separated by commas and optional " "whitespace. This rule's keys and an explanation of each of them are as " "follows:" msgstr "" #. type: Content of: <sect1><sect2><sect3><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:79 msgid "" "<literal>SUBSYSTEM==\"net\"</literal> - This tells udev to ignore devices " "that are not network cards." msgstr "" #. type: Content of: <sect1><sect2><sect3><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:83 msgid "" "<literal>ACTION==\"add\"</literal> - This tells udev to ignore this rule for " "a uevent that isn't an add (\"remove\" and \"change\" uevents also happen, " "but don't need to rename network interfaces)." msgstr "" #. type: Content of: <sect1><sect2><sect3><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:88 msgid "" "<literal>DRIVERS==\"?*\"</literal> - This exists so that udev will ignore " "VLAN or bridge sub-interfaces (because these sub-interfaces do not have " "drivers). These sub-interfaces are skipped because the name that would be " "assigned would collide with their parent devices." msgstr "" #. type: Content of: <sect1><sect2><sect3><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:94 msgid "" "<literal>ATTR{address}</literal> - The value of this key is the NIC's MAC " "address." msgstr "" #. type: Content of: <sect1><sect2><sect3><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:98 msgid "" "<literal>ATTR{type}==\"1\"</literal> - This ensures the rule only matches " "the primary interface in the case of certain wireless drivers which create " "multiple virtual interfaces. The secondary interfaces are skipped for the " "same reason that VLAN and bridge sub-interfaces are skipped: there would be " "a name collision otherwise." msgstr "" #. type: Content of: <sect1><sect2><sect3><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:105 msgid "" "<literal>NAME</literal> - The value of this key is the name that udev will " "assign to this interface." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:110 msgid "" "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 " "proceeding, and be sure to use that <literal>NAME</literal> value when " "creating your configuration files below." msgstr "" #. type: Content of: <sect1><sect2><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:121 msgid "CD-ROM symlinks" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:123 msgid "" "Some software that you may want to install later (e.g., various media " "players) expect the <filename class=\"symlink\">/dev/cdrom</filename> and " "<filename class=\"symlink\">/dev/dvd</filename> symlinks to exist, and to " "point to a CD-ROM or DVD-ROM device. Also, it may be convenient to put " "references to those symlinks into <filename>/etc/fstab</filename>. Udev " "comes with a script that will generate rules files to create these symlinks " "for you, depending on the capabilities of each device, but you need to " "decide which of two modes of operation you wish to have the script use." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:132 msgid "" "First, the script can operate in <quote>by-path</quote> mode (used by " "default for USB and FireWire devices), where the rules it creates depend on " "the physical path to the CD or DVD device. Second, it can operate in " "<quote>by-id</quote> mode (default for IDE and SCSI devices), where the " "rules it creates depend on identification strings stored on the CD or DVD " "device itself. The path is determined by udev's <command>path_id</command> " "script, and the identification strings are read from the hardware by its " "<command>ata_id</command> or <command>scsi_id</command> programs, depending " "on which type of device you have." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:142 msgid "" "There are advantages to each approach; the correct approach to use will " "depend on what kinds of device changes may happen. If you expect the " "physical path to the device (that is, the ports and/or slots that it plugs " "into) to change, for example because you plan on moving the drive to a " "different IDE port or a different USB connector, then you should use the " "<quote>by-id</quote> mode. On the other hand, if you expect the device's " "identification to change, for example because it may die, and you would " "replace it with a different device with the same capabilities and which is " "plugged into the same connectors, then you should use the " "<quote>by-path</quote> mode." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:153 msgid "" "If either type of change is possible with your drive, then choose a mode " "based on the type of change you expect to happen more often." msgstr "" #. type: Content of: <sect1><sect2><important><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:159 msgid "" "External devices (for example, a USB-connected CD drive) should not use " "by-path persistence, because each time the device is plugged into a new " "external port, its physical path will change. All externally-connected " "devices will have this problem if you write udev rules to recognize them by " "their physical path; the problem is not limited to CD and DVD drives." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:166 msgid "" "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 <filename " "class=\"directory\">/sys</filename> (e.g., this can be <filename " "class=\"directory\">/sys/block/hdd</filename>) and run a command similar to " "the following:" msgstr "" #. type: Content of: <sect1><sect2><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:172 #, no-wrap msgid "<userinput>udevadm test /sys/block/hdd</userinput>" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:174 msgid "" "Look at the lines containing the output of various *_id programs. The " "<quote>by-id</quote> mode will use the ID_SERIAL value if it exists and is " "not empty, otherwise it will use a combination of ID_MODEL and " "ID_REVISION. The <quote>by-path</quote> mode will use the ID_PATH value." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:179 msgid "" "If the default mode is not suitable for your situation, then the following " "modification can be made to the " "<filename>/etc/udev/rules.d/83-cdrom-symlinks.rules</filename> file, as " "follows (where <replaceable>mode</replaceable> is one of " "<quote>by-id</quote> or <quote>by-path</quote>):" msgstr "" #. type: Content of: <sect1><sect2><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:185 #, no-wrap msgid "" "<userinput>sed -e 's/\"write_cd_rules\"/\"write_cd_rules " "<replaceable>mode</replaceable>\"/' \\\n" " -i /etc/udev/rules.d/83-cdrom-symlinks.rules</userinput>" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:188 msgid "" "Note that it is not necessary to create the rules files or symlinks at this " "time because you have bind-mounted the host's <filename " "class=\"directory\">/dev</filename> directory into the LFS system and we " "assume the symlinks exist on the host. The rules and symlinks will be " "created the first time you boot your LFS system." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:194 msgid "" "However, if you have multiple CD-ROM devices, then the symlinks generated at " "that time may point to different devices than they point to on your host " "because devices are not discovered in a predictable order. The assignments " "created when you first boot the LFS system will be stable, so this is only " "an issue if you need the symlinks on both systems to point to the same " "device. If you need that, then inspect (and possibly edit) the generated " "<filename>/etc/udev/rules.d/70-persistent-cd.rules</filename> file after " "booting, to make sure the assigned symlinks match what you need." msgstr "" #. type: Content of: <sect1><sect2><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:207 msgid "Dealing with duplicate devices" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:209 msgid "" "As explained in <xref linkend=\"ch-config-udev\"/>, the order in which " "devices with the same function appear in <filename " "class=\"directory\">/dev</filename> is essentially random. E.g., if you " "have a USB web camera and a TV tuner, sometimes " "<filename>/dev/video0</filename> refers to the camera and " "<filename>/dev/video1</filename> refers to the tuner, and sometimes after a " "reboot the order changes. 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 " "<xref linkend=\"ch-config-network\"/>, and sound card configuration can be " "found in <ulink url=\"&blfs-book;postlfs/devices.html\">BLFS</ulink>." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:222 msgid "" "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 <filename " "class=\"directory\">/sys/class</filename> or <filename " "class=\"directory\">/sys/block</filename>. For video devices, this may be " "<filename " "class=\"directory\">/sys/class/video4linux/video<replaceable>X</replaceable></filename>. " "Figure out the attributes that identify the device uniquely (usually, vendor " "and product IDs and/or serial numbers work):" msgstr "" #. type: Content of: <sect1><sect2><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:233 #, no-wrap msgid "<userinput>udevadm info -a -p /sys/class/video4linux/video0</userinput>" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:235 msgid "Then write rules that create the symlinks, e.g.:" msgstr "" #. type: Content of: <sect1><sect2><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:237 #, no-wrap msgid "" "<userinput>cat > /etc/udev/rules.d/83-duplicate_devs.rules << " "\"EOF\"\n" "<literal>\n" "# Persistent symlinks for webcam and tuner\n" "KERNEL==\"video*\", ATTRS{idProduct}==\"1910\", ATTRS{idVendor}==\"0d81\", " "SYMLINK+=\"webcam\"\n" "KERNEL==\"video*\", ATTRS{device}==\"0x036f\", ATTRS{vendor}==\"0x109e\", " "SYMLINK+=\"tvtuner\"\n" "</literal>\n" "EOF</userinput>" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:245 msgid "" "The result is that <filename>/dev/video0</filename> and " "<filename>/dev/video1</filename> devices still refer randomly to the tuner " "and the web camera (and thus should never be used directly), but there are " "symlinks <filename>/dev/tvtuner</filename> and " "<filename>/dev/webcam</filename> that always point to the correct device." msgstr ""

# SOME DESCRIPTIVE TITLE # Copyright (C) YEAR Free Software Foundation, Inc. # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 2020-06-17 12:44+0800\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "Language: \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. type: Content of: #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:11 msgid "Managing Devices" msgstr "" #. type: Content of: <sect1><sect2><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:15 msgid "Network Devices" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:17 msgid "" "Udev, by default, names network devices according to Firmware/BIOS data or " "physical characteristics like the bus, slot, or MAC address. The purpose of " "this naming convention is to ensure that network devices are named " "consistently and not based on the time the network card was discovered. For " "example, on a computer having two network cards made by Intel and Realtek, " "the network card manufactured by Intel may become eth0 and the Realtek card " "becomes eth1. In some cases, after a reboot the cards could get renumbered " "the other way around." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:26 msgid "" "In the new naming scheme, typical network device names would then be " "something like enp5s0 or wlp3s0. If this naming convention is not desired, " "the traditional naming scheme or a custom scheme can be implemented." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:32 msgid "Disabling Persistent Naming on the Kernel Command Line" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:34 msgid "" "The traditional naming scheme using eth0, eth1, etc can be restored by " "adding <userinput>net.ifnames=0</userinput> on the kernel command line. " "This is most appropriate for those systems that have only one ethernet " "device of the same type. Laptops often have multiple ethernet connections " "that are named eth0 and wlan0 and are also candidates for this method. The " "command line is passed in the GRUB configuration file. See <xref " "linkend=\"grub-cfg\"/>." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:45 msgid "Creating Custom Udev Rules" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:47 msgid "" "The naming scheme can be customized by creating custom udev rules. A script " "has been included that generates the initial rules. Generate these rules by " "running:" msgstr "" #. type: Content of: <sect1><sect2><sect3><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:51 #, no-wrap msgid "<userinput>bash /lib/udev/init-net-rules.sh</userinput>" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:53 msgid "" "Now, inspect the " "<filename>/etc/udev/rules.d/70-persistent-net.rules</filename> file, to find " "out which name was assigned to which network device:" msgstr "" #. type: Content of: <sect1><sect2><sect3><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:57 #, no-wrap msgid "<userinput>cat /etc/udev/rules.d/70-persistent-net.rules</userinput>" msgstr "" #. type: Content of: <sect1><sect2><sect3><note><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:59 msgid "" "In some cases such as when MAC addresses have been assigned to a network " "card manually or in a virtual environment such as Qemu or Xen, the network " "rules file may not have been generated because addresses are not " "consistently assigned. In these cases, this method cannot be used." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:65 msgid "" "The file begins with a comment block followed by two lines for each NIC. The " "first line for each NIC is a commented description 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. Neither the hardware ID " "nor the driver is used to determine which name to give an interface; this " "information is only for reference. The second line is the udev rule that " "matches this NIC and actually assigns it a name." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:73 msgid "" "All udev rules are made up of several keys, separated by commas and optional " "whitespace. This rule's keys and an explanation of each of them are as " "follows:" msgstr "" #. type: Content of: <sect1><sect2><sect3><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:79 msgid "" "<literal>SUBSYSTEM==\"net\"</literal> - This tells udev to ignore devices " "that are not network cards." msgstr "" #. type: Content of: <sect1><sect2><sect3><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:83 msgid "" "<literal>ACTION==\"add\"</literal> - This tells udev to ignore this rule for " "a uevent that isn't an add (\"remove\" and \"change\" uevents also happen, " "but don't need to rename network interfaces)." msgstr "" #. type: Content of: <sect1><sect2><sect3><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:88 msgid "" "<literal>DRIVERS==\"?*\"</literal> - This exists so that udev will ignore " "VLAN or bridge sub-interfaces (because these sub-interfaces do not have " "drivers). These sub-interfaces are skipped because the name that would be " "assigned would collide with their parent devices." msgstr "" #. type: Content of: <sect1><sect2><sect3><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:94 msgid "" "<literal>ATTR{address}</literal> - The value of this key is the NIC's MAC " "address." msgstr "" #. type: Content of: <sect1><sect2><sect3><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:98 msgid "" "<literal>ATTR{type}==\"1\"</literal> - This ensures the rule only matches " "the primary interface in the case of certain wireless drivers which create " "multiple virtual interfaces. The secondary interfaces are skipped for the " "same reason that VLAN and bridge sub-interfaces are skipped: there would be " "a name collision otherwise." msgstr "" #. type: Content of: <sect1><sect2><sect3><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:105 msgid "" "<literal>NAME</literal> - The value of this key is the name that udev will " "assign to this interface." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:110 msgid "" "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 " "proceeding, and be sure to use that <literal>NAME</literal> value when " "creating your configuration files below." msgstr "" #. type: Content of: <sect1><sect2><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:121 msgid "CD-ROM symlinks" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:123 msgid "" "Some software that you may want to install later (e.g., various media " "players) expect the <filename class=\"symlink\">/dev/cdrom</filename> and " "<filename class=\"symlink\">/dev/dvd</filename> symlinks to exist, and to " "point to a CD-ROM or DVD-ROM device. Also, it may be convenient to put " "references to those symlinks into <filename>/etc/fstab</filename>. Udev " "comes with a script that will generate rules files to create these symlinks " "for you, depending on the capabilities of each device, but you need to " "decide which of two modes of operation you wish to have the script use." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:132 msgid "" "First, the script can operate in <quote>by-path</quote> mode (used by " "default for USB and FireWire devices), where the rules it creates depend on " "the physical path to the CD or DVD device. Second, it can operate in " "<quote>by-id</quote> mode (default for IDE and SCSI devices), where the " "rules it creates depend on identification strings stored on the CD or DVD " "device itself. The path is determined by udev's <command>path_id</command> " "script, and the identification strings are read from the hardware by its " "<command>ata_id</command> or <command>scsi_id</command> programs, depending " "on which type of device you have." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:142 msgid "" "There are advantages to each approach; the correct approach to use will " "depend on what kinds of device changes may happen. If you expect the " "physical path to the device (that is, the ports and/or slots that it plugs " "into) to change, for example because you plan on moving the drive to a " "different IDE port or a different USB connector, then you should use the " "<quote>by-id</quote> mode. On the other hand, if you expect the device's " "identification to change, for example because it may die, and you would " "replace it with a different device with the same capabilities and which is " "plugged into the same connectors, then you should use the " "<quote>by-path</quote> mode." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:153 msgid "" "If either type of change is possible with your drive, then choose a mode " "based on the type of change you expect to happen more often." msgstr "" #. type: Content of: <sect1><sect2><important><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:159 msgid "" "External devices (for example, a USB-connected CD drive) should not use " "by-path persistence, because each time the device is plugged into a new " "external port, its physical path will change. All externally-connected " "devices will have this problem if you write udev rules to recognize them by " "their physical path; the problem is not limited to CD and DVD drives." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:166 msgid "" "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 <filename " "class=\"directory\">/sys</filename> (e.g., this can be <filename " "class=\"directory\">/sys/block/hdd</filename>) and run a command similar to " "the following:" msgstr "" #. type: Content of: <sect1><sect2><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:172 #, no-wrap msgid "<userinput>udevadm test /sys/block/hdd</userinput>" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:174 msgid "" "Look at the lines containing the output of various *_id programs. The " "<quote>by-id</quote> mode will use the ID_SERIAL value if it exists and is " "not empty, otherwise it will use a combination of ID_MODEL and " "ID_REVISION. The <quote>by-path</quote> mode will use the ID_PATH value." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:179 msgid "" "If the default mode is not suitable for your situation, then the following " "modification can be made to the " "<filename>/etc/udev/rules.d/83-cdrom-symlinks.rules</filename> file, as " "follows (where <replaceable>mode</replaceable> is one of " "<quote>by-id</quote> or <quote>by-path</quote>):" msgstr "" #. type: Content of: <sect1><sect2><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:185 #, no-wrap msgid "" "<userinput>sed -e 's/\"write_cd_rules\"/\"write_cd_rules " "<replaceable>mode</replaceable>\"/' \\\n" " -i /etc/udev/rules.d/83-cdrom-symlinks.rules</userinput>" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:188 msgid "" "Note that it is not necessary to create the rules files or symlinks at this " "time because you have bind-mounted the host's <filename " "class=\"directory\">/dev</filename> directory into the LFS system and we " "assume the symlinks exist on the host. The rules and symlinks will be " "created the first time you boot your LFS system." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:194 msgid "" "However, if you have multiple CD-ROM devices, then the symlinks generated at " "that time may point to different devices than they point to on your host " "because devices are not discovered in a predictable order. The assignments " "created when you first boot the LFS system will be stable, so this is only " "an issue if you need the symlinks on both systems to point to the same " "device. If you need that, then inspect (and possibly edit) the generated " "<filename>/etc/udev/rules.d/70-persistent-cd.rules</filename> file after " "booting, to make sure the assigned symlinks match what you need." msgstr "" #. type: Content of: <sect1><sect2><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:207 msgid "Dealing with duplicate devices" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:209 msgid "" "As explained in <xref linkend=\"ch-config-udev\"/>, the order in which " "devices with the same function appear in <filename " "class=\"directory\">/dev</filename> is essentially random. E.g., if you " "have a USB web camera and a TV tuner, sometimes " "<filename>/dev/video0</filename> refers to the camera and " "<filename>/dev/video1</filename> refers to the tuner, and sometimes after a " "reboot the order changes. 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 " "<xref linkend=\"ch-config-network\"/>, and sound card configuration can be " "found in <ulink url=\"&blfs-book;postlfs/devices.html\">BLFS</ulink>." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:222 msgid "" "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 <filename " "class=\"directory\">/sys/class</filename> or <filename " "class=\"directory\">/sys/block</filename>. For video devices, this may be " "<filename " "class=\"directory\">/sys/class/video4linux/video<replaceable>X</replaceable></filename>. " "Figure out the attributes that identify the device uniquely (usually, vendor " "and product IDs and/or serial numbers work):" msgstr "" #. type: Content of: <sect1><sect2><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:233 #, no-wrap msgid "<userinput>udevadm info -a -p /sys/class/video4linux/video0</userinput>" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:235 msgid "Then write rules that create the symlinks, e.g.:" msgstr "" #. type: Content of: <sect1><sect2><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:237 #, no-wrap msgid "" "<userinput>cat > /etc/udev/rules.d/83-duplicate_devs.rules << " "\"EOF\"\n" "<literal>\n" "# Persistent symlinks for webcam and tuner\n" "KERNEL==\"video*\", ATTRS{idProduct}==\"1910\", ATTRS{idVendor}==\"0d81\", " "SYMLINK+=\"webcam\"\n" "KERNEL==\"video*\", ATTRS{device}==\"0x036f\", ATTRS{vendor}==\"0x109e\", " "SYMLINK+=\"tvtuner\"\n" "</literal>\n" "EOF</userinput>" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/symlinks.xml:245 msgid "" "The result is that <filename>/dev/video0</filename> and " "<filename>/dev/video1</filename> devices still refer randomly to the tuner " "and the web camera (and thus should never be used directly), but there are " "symlinks <filename>/dev/tvtuner</filename> and " "<filename>/dev/webcam</filename> that always point to the correct device." msgstr ""