If you've been using Linux for a long time, then you know that Linux has changed several strategies in the case of device files. Early in Linux, the device files were just plain files with the appropriate set of attributes, created by the Mknod command and stored in the/dev directory. Later, using DEVFS, a kernel-based dynamic device file system, he first appeared in the 2.3.46 kernel. Linux distribution versions such as Mandrake,gentoo are used this way. The device files created by DEVFS are dynamic. But DEVFS has some serious limitations, removed from the 2.6.13 release. The current replacement for him is the text to be mentioned udev--a user-space program.
A lot of Linux distributions now adopt the UDEV approach, as it solves several problems on Linux device access, especially those that have extreme requirements for devices such as the need to control thousands of hard drives, and hot-swappable devices such as USB cameras and MP3 players. Let's take a look at how to manage udev devices.
In fact, you don't need to modify anything for standard profiles that are prepared for disks, end devices, and so on. However, you need to understand the Udev configuration to use new or exotic devices, and if you do not modify the configuration, these devices may not be accessible, or Linux may use inappropriate names, which are groups or permissions to create these device files. You may also want to know how to modify the RS-232 serial, audio device and other files belonging to the group or permissions. This is something that you will encounter in the actual Linux implementation.
Why use Udev
Previous device file management methods (static files and DEVFS) have several drawbacks:
* Indeterminate device mappings. In particular, the mapping of dynamic devices such as USB devices, device files to actual devices is unreliable and deterministic. Give an example: if you have two USB printers. One may be called/dev/usb/lp0, and the other is/DEV/USB/LP1. But in the end which is not clear, LP0,LP1 and the actual device does not have one by one corresponding relationship, because he may be found in the order of the device, the printer itself shut down and other reasons such mapping is not determined. Ideally, the two printers should be mapped using a unique device file based on their serial number or other identifying information. But neither static files nor Devfs can do this.
* There are not enough primary/secondary device numbers. We know that each device file has two 8-bit numbers: One is the main device number, the other is the secondary device number to allocate. These two 8-bit numbers are combined with the device type (block device or character device) to uniquely identify a device. Unfortunately, it's not enough to correlate the numbers around them.
There are too many files in the */dev directory. A system using static Device file association, then this directory of files must be enough. And at the same time you don't know what the device files are active on your system.
* Name is not flexible. Although Devfs solves some of the previous problems, it itself poses some problems. One of them is the name is not flexible enough, you can not be very simple to modify the device file names. The default DEVFS command mechanism itself is also very strange, he needs to modify a large number of configuration files and programs.;
* Kernel memory use, DEVFS unique another problem is that as a kernel driver module, DEVFS needs to consume a lot of memory, especially when there are a large number of devices on the system (such as the above mentioned system on a good thousands of disk)
Udev's goal is to address the above mentioned issues, he uses the user space (User-space) tool to manage the/dev/directory tree, he and the file system separate. Knowing how to change the default configuration can make you big how to customize your own system, such as creating device character connections, changing device file groups, permissions, and so on.
udev configuration file
The primary udev configuration file is
/etc/udev/udev.conf。 This file is usually very short, he may just include a few lines of # beginning of the comment, and then have a few lines of options:
udev_root= "/dev/" udev_rules= "/etc/udev/rules.d/" udev_log= "Err"
The second line above is very important because he represents the directory where Udev rules are stored, and this directory stores files that end in. Rules. Each file handles a series of rules to help udev assign names to device files to ensure that they are recognized by the kernel.
Yours
/ETC/UDEV/RULES.DThere may be several Udev rule files, some of which are installed by the Udev package, and the other part may be generated by other hardware or software packages. For example, on the Fedora Core 5 system, the Sane-backends package installs the 60-libsane.rules file, and the initscripts package installs 60-net.rules files. The file names of these rule files are usually the beginning of two digits, which indicates the order in which the rule is applied by the system.
The rules in the rules file have a series of key/value pairs, separated by a comma (,) between the key/value pairs. Each key is either a user-matching key or an assignment key. The match key determines whether the rule is applied, and the assignment key indicates that a value is assigned to the key. These values will affect the device files created by Udev. An assignment key can handle a multivalued list.
Rule Description
1. All the operators of Udev rules
"= =":The comparison key, the value, if equal, then the condition satisfies;
"! =":The comparison key, the value, if not equal, then the condition satisfies;
"=":Assign a value to a key;
"+ =":Assigns a value to a key that represents multiple entries.
": =":Assigns a value to a key and rejects any subsequent changes to the key. The goal is to prevent subsequent rules files from assigning a value to the key.
2. The matching key of Udev rules
ACTION:Event (uevent) behavior, for example: Add (Add Device), remove (remove device).
KERNEL:Kernel device name, for example: SDA, CDROM.
DEVPATH:The Devpath path of the device.
SUBSYSTEM:The subsystem name of the device, for example: SDA subsystem is block.
BUS:The bus name of the device in the Devpath, for example: USB.
DRIVER:Device driver name in Devpath, for example: Ide-cdrom.
ID:Identification number of the device in the Devpath.
Sysfs{filename}:Device's Devpath path, the contents of the device's properties file "FileName".
For example: sysfs{model}== "st936701ss" means that if the device's model number is ST936701SS, the device matches the matching key.
In one rule, you can set a matching key for up to five SYSFS.
Env{key}:Environment variables. In one rule, you can set a matching key for up to five environment variables.
Program :Call the external command.
RESULT:The return result of the external command program.
3. Important assignment keys for Udev
NAME:The file name of the device generated under/dev. Only the first assignment of the name of a device takes effect, and then the matching rule is ignored for the name assignment behavior of the device. If no rules are assigned to the name of the device, Udev uses the kernel device name to generate the device files.
SYMLINK:Generates a symbolic link for a device file under/dev/. Because Udev can only produce one device file for a device, it is recommended to use symbolic links in order not to overwrite files produced by the system's default Udev rules.
OWNER, GROUP, MODE:Set permissions for the device.
Env{key}:Import an environment variable.
4. Udev values and callable substitution operatorsLinux users are free to customize the values of Udev rules files. For example: My_root_disk, My_printer. You can also refer to the following substitution operators:
$kernel,%k:The device's kernel device name, for example: SDA, CDROM.
$number,%n:The kernel number of the device, for example: Sda3 The kernel number is 3.
$devpath,%p:The Devpath path of the device.
$id,%b:The ID number of the device in the Devpath.
$sysfs {file},%s{file}:The contents of the file in the Sysfs of the device. is actually the property value of the device.
$env {key},%e{key}:The value of an environment variable.
$major,%M:The major number of the device.
$minor%m:The minor number of the device.
$result,%c:The result of the program return.
$parent,%P:The device file name of the parent device.
$root,%r:The value of Udev_root, which is/dev/by default.
$tempnode,%N:The temporary device name.
Percent :Symbol% itself.
$$:Symbol $ itself.
Given an example to explain how to use these keys, the following examples come from the standard configuration file for the Fedora Core 5 system:
kernel== "*", owner= "root" group= "root", mode= "0600" kernel== "TTY", name= "%k", group= "TTY", mode= "0666", options= "Last_ Rule "kernel==" scd[0-9]* ", symlink+=" cdrom cdrom-%k "kernel==" hd[a-z] ", bus==" IDE ", sysfs{removable}==" 1 ", sysfs{ device/media}== "cdrom", symlink+= "cdrom cdrom-%k" action== "Add", subsystem== "Scsi_device", run+= "/sbin/modprobe sg"
The above example gives 5 rules, each of which is the beginning of the kernel or action key:
* The first rule is the default, he matches any device identified by the kernel, and then set the group of these devices is root, the group is root, access rights mode is 0600 (-RW-------). This is also a safe default setting to ensure that all devices are read and written by default only by Root. * The second rule is also a more typical rule. It matches the end device (TTY), and then sets the new permission to 0600, where the group is TTY. It also sets a special device file name:%K. In this example,%k represents the kernel name of the device. That means that the kernel recognizes what the device name is and creates the device file name. * The third line starts with the kernel== "scd[0-9]*", which indicates the SCSI CD-ROM drive. It creates a pair of device symbolic connections: CDROM and cdrom-%k. * Line fourth, starting with kernel== "Hd[a-z]", represents the ATA CDROM drive. This rule creates the same symbolic connection as the above rule. ATA CDROM drives require a SYSFS value to differentiate other ATA devices since SCSI CDROM can be uniquely identified by the kernel. * Line fifth starts with action== "add", which tells Udev to add/sbin/modprobe sg to the list of commands that will be executed when any SCSI device is added to the system. The effect is that the computer should increase the SG Kernel module to detect new SCSI devices.
Of course, the above is just a small example, if your system takes the form of udev, you should see more rules. If you want to modify the permissions of a device or create a symbolic connection to a letter, you need to familiarize yourself with these rules, especially with regard to the devices that you modify.
Modify your Udev configuration
Before modifying the Udev configuration, we have to be careful, the usual consideration is: you'd better not modify the rules of the system presets, especially not to specify a very extensive configuration, such as the first line in the example above. Improper configuration can cause serious system problems or the system will not be able to access the device at all.
And the right thing to do is to create a rule file for a letter under/etc/udev/rules.d/. Make sure you give the file a suffix that the rules file name gives a sequence of numbers that should be higher than the standard configuration file. For example, you can create a rule file named 99-my-udev.rules. In your rules file, you can specify any configuration you want to modify, for example, if you modify the group that modifies the floppy device, and you are ready to create a symbolic connection/dev/floppy of the letter, then you can write:
kernel== "fd[0-9]*", group= "users", symlink+= "floppy"
Some distributions, such as Fedora, use an external script to modify the group, group relationships, and permissions for certain devices. Therefore, the above changes may not be effective. If you encounter this problem, you need to track and modify the script to achieve your goal. Or you can change the value of the program or run key to do this.
Modifications to some rules may require deeper digging. For example, you might want to use SYSFS information on a device to uniquely identify a device. This information is best obtained through the Udevinfo command.
$
udevinfo–a–p $ (udevinfo–q path–n/dev/hda)
The above command two times to use Udevinfo: Once is to return the SYSFS device path (he usually and we see the Linux device file name is located in the same path--/dev/hda--); the second time is to query the device path, the results will be non-frequent SYFS information summary. You can find the best information to uniquely flag your device and you can use the SYSFS option in the appropriate replacement udev configuration file. The following result is the command output above
[Email protected] rules.d]#
Udevinfo-a-P $ (udevinfo-q path-n/dev/hda1)
Udevinfo starts with the device specified by the Devpath and thenwalks up the chain of the parent devices. It prints for every devicefound, all possible attributes in the UDEV rules key format. A rule to match, can is composed by the attributes of the Deviceand the attributes from one single parent device.looking a T device '/block/hda/hda1 ': kernel== "hda1" subsystem== "block" driver== "" attr{stat}== "1133 2268 2 4" attr{size}== "208782 "attr{start}==" attr{dev}== "3:1" Looking at parent device '/block/hda ': kernels== "Hda" subsystems== "block" drivers== "attrs{stat}==" 28905 18814 1234781 302540 34087 133247 849708 981336 0 218340 1283968 "attrs{size}==" 117210240 "ATTRS{rem ovable}== "0" attrs{range}== "attrs{dev}==" 3:0 "Looking at parent device '/devices/pci0000:00/0000:00:1f.1/ide0/0.0 ': kernels== "0.0" subsystems== "IDE" drivers== "Ide-disk" attrs{modalias}== "Ide:m-disk" attrs{drivename}== "HDA" ATTRS{ media}== "Disk" Looking at parent device '/devices/pci0000:00/0000:00:1f.1/ide0 ': kernels== "ide0" subsystems== "" DRIVERs== "" Looking at Parent device '/DEVICES/PCI0000:00/0000:00:1F.1 ': kernels== "0000:00:1F.1" subsystems== "PCI" DRIVERS== "Piix_ide" attrs{broken_parity_status}== "0" attrs{enable}== "1" attrs{modalias}== "PCI: v00008086d000024casv0000144dsd0000c009bc01sc01i8a "attrs{local_cpus}==" 1 "attrs{irq}==" ATTRS{class}== " 0x01018a "attrs{subsystem_device}==" 0xc009 "attrs{subsystem_vendor}==" 0x144d "attrs{device}==" 0x24ca "ATTRS{vendor }== "0x8086" Looking at parent device '/devices/pci0000:00 ': kernels== "pci0000:00" subsystems== "" drivers== ""
Example One: Modify the configuration of the USB scanner. With a series of attempts, you've identified a Linux device file for this scanner (the name changes every time you open the scanner). You can replace the correct Linux device file name with the above command, and then locate the output with Sysfs{idvendor} lines and sysfs{idproduct} rows. Finally, you can use this information to create new options for this scanner.
sysfs{idvendor}== "0686", sysfs{idproduct}== "400e", symlink+= "scanner", mode= "0664", group= "scanner"
The example above indicates that the scanner's group is set to scanner, the access permission is set to 0664, and a/dev/scanner symbolic connection is created.
Example two: using Udev to modify the U-disk device file name
Write our/etc/udev/rules.d/10-local.rules file
sudo vim/etc/udev/rules.d/10-local.rules
Add these variable information to the following:
kernel== "SDC4", subsystems== "block", name+= "Kinstonusb", symlink+= "Kinstonusb_link"
Above the kernel== "Sdc4", subsystems== "block" We can copy the past directly according to the above output. We save this file.
Generally we want this rule file to take effect, to hot-plug our device to generate an event or add information to the event file in the device to update our UDEV rules for the purpose of sending events, but there is a more convenient way to run the following command.
sudo udevadm test/sys/class/block/sdc4
So we update our rules.
Look at the situation in/dev, such as:
Look at SDC, such as:
Sdc4 disappeared, that is, we named our sdc4 for Kinstonusb, and there is a kinstonusb_link link to it, we will be available/dev/kinstonusb or/dev/kinstonusb_ Link to operate our USB drive instead of/DEV/SDC4.
---------------------------------------------------------------------------------
Understanding and understanding Udev
Because of itself engaged in the storage industry, many times in the work encountered the user has this request: My Linux system originally has a SCSI hard disk, the system allocates the device file is/DEV/SDA. A new external disk array is now added and is connected via a SCSI card. But after this disk array,/DEV/SDA became a disk array of hard disk, the original built-in SCSI hard drive into the/DEV/SDB, I want to fix the device files.
In the past, I always said to the user, this is more troublesome, because the/DEV/SDA and other files are automatically assigned by the Linux kernel. It's hard to fix it, unless you change the order in which the SCSI card drivers are loaded, so that the drive module of the SCSI card connected by the internal hard disk connection to the external disk array is loaded into the kernel first, so that the/DEV/SDA always points to the built-in hard drive. However, this solution is not perfect after all, and for other Plug and Play devices, such as USB devices are not applicable.
Recently, by installing and upgrading the linux-2.6 kernel, it has been discovered that this problem can be solved by the new Sysfs file system and the Udev program of the 2.6 kernel. Here's what I learned from the Udev configuration. I like to explain it in the form of FAQs.
Q: What is Udev?
A: Udev is a tool that dynamically updates the device files according to the state of the hardware devices in the system, including the creation, deletion, etc. of the device files. The device files are usually placed in the/dev directory. With Udev, only the devices that really exist in the system are included in the/dev directory.
Q: What kernel does udev support?
A: Udev only supports the linux-2.6 kernel, because Udev relies heavily on the information provided by the Sysfs file system, whereas the Sysfs file system is only available in the linux-2.6 kernel.
Q: Is udev a kernel program or a user program?
A: Udev is a user program (User-mode daemon).
Q: What is the difference between Udev and DEVFS?
A: Udev is able to implement all the functions that DEVFS implements. But Udev runs in user mode, while DEVFS runs in the kernel. It is said that Devfs has some congenital defects that are not easily resolved.
Q: Where is the udev configuration file placed?
A: Udev is a user-mode program. Its configuration file is/etc/udev/udev.conf. This file typically has these items by default:
udev_root= "/dev"; The root directory of the device files produced by Udev is/dev
udev_db= "/dev/.udevdb"; A database formed from a device file produced by Udev
Udev_rules= "/ETC/UDEV/RULES.D"; the directory where the rules used to guide udev work.
Udev_log= "Err", when an error occurs, the error message is logged with the syslog.
Q: What is the working process of udev?
A: Since we have not studied the source program of Udev, I dare not say the work process of udev. I'm just using some of the information on the web and the Udev documentation to roughly guess how it might work.
1. When the kernel detects that a new device appears in the system, the kernel generates a new record for the new device in the Sysfs file system, and the Sysfs file system is typically mount to the/sys directory. The new record is represented as one or more files or directories. Each file contains specific information. (How does the information be expressed and what else should be studied?) ）
2. Udev is UDEVD in the system in the form of a daemon, and it passes some way (in the end, it is not understood at all.) ) detects the presence of a new device and obtains some information about the device by locating records in the corresponding SYSFS of the device.
3. Udev examines the files in this directory, based on the directory specified in the/etc/udev/udev.conf file Udev_rules, and the files in this directory are rules files that are intended to be implemented for a class or device. Udev reads files according to the ASCII alphabetical order of the filenames, and if Udev finds a rule that matches the newly added device, Udev configures the new device according to the actions defined by the rule. The subsequent rule files are not read at the same time.
Q: What is the syntax of Udev's rules file?
A: Udev's rules file is in the behavior unit, and the line that begins with "#" represents the comment line. Each of the remaining lines represents a rule. Each rule is divided into one or more "match" and "assignment" sections. The match section is represented by a keyword that is specific to match, and the corresponding assignment section is represented by the keyword assigned to it. The "Match" keyword includes: Action,kernel,bus, SYSFS, etc., the "assignment" keyword includes: Name,symlink,owner, and so on. Detailed descriptions can read the Udev man documentation.
Here is an example of a rule:
subsystem== "NET", action== "Add", sysfs{address}== "00:0d:87:f6:59:f3", import= "/sbin/rename_netiface%k eth0"
The "Match" section in this rule has three items, namely Subsystem,action and SYSFS. In the "Assignment" section there is an import. This rule means that when the new hardware appearing in the system belongs to the net subsystem category, the system takes the action to join this hardware, and this hardware in the Sysfs file system "address" information equals "00:0d ...", The action of this hardware at the udev level is to invoke the external program/sbin/rename_netiface, passing parameters of two, one is "%k", which represents the name of the kernel for the new device definition. The other is "eth0".
As can be seen from the above example, Udev's rules are more flexible, especially in the "Match" section, where you can flexibly match multiple matches by using shell wildcard characters such as "*", "?", [a-c],[1-9], and so on. The specific syntax can refer to the Udev man document.
Q: How does Udev maintain a unified device name regardless of the order in which the devices are connected?
A: In fact, Udev achieves this by adding aliases to the device names generated by the kernel. As mentioned earlier, Udev is a user-mode program that does not change the behavior of the kernel. As a result, the kernel will continue to produce device names such as Sda,sdb. However, Udev can differentiate different devices and produce device files based on other information, such as bus, manufacturer (vendor), and other devices. Udev can solve this problem by simply taking a fixed file name for the device file. In subsequent operations on the device, simply refer to the new device name. But in order to ensure maximum compatibility, in general, the new device name is always used as a symbolic link to the device name automatically generated by the kernel.
For example: The kernel generated the SDA device name, and according to the information, this device corresponds to my internal hard drive, then I can make udev rules, so that udev in addition to generating/DEV/SDA device files, in addition to create a symbolic link called/DEV/INTERNALHD. In this way, I in the Fstab file, you can use/DEV/INTERNALHD to replace the original/DEV/SDA. Next time, for some reason, the hard drive has become a SDB device name in the kernel, so don't worry, Udev will automatically generate/DEV/INTERNALHD this link and point to the correct/dev/sdb device. All other files such as fstab are not modified.
Q: How can I find these device information and put them in the Udev rules file to match it?
A: This problem is difficult, the online information is not much, I only found an article to describe how to write udev rules. His basic approach is to use the Udevinfo utility to find items that can be used as matches in a rule file. There are two scenarios in which this tool can be used:
In the first case, when you plug the device into the system, the system generates a device name (such as/DEV/SDA) for the device. In that case, you first use udevinfo-q path-n/DEV/SDA, command will produce a device name corresponding to the path under the SYSFS, such as/BLOCK/SDA. Then, with Udevinfo-a-p/sys/block/sda, this command displays a bunch of messages, divided into chunks. This information is actually derived from the SYSFS linked list maintained by the operating system, and different blocks correspond to different paths. You can use this information as a match in the Udev rules file. However, it is important to note that the same rule can only use the information displayed in the same block and cannot write rules across blocks.
The second situation is, do not know the system produces the device name, then only to the/sys directory down directory search, repeatedly used Udevinfo-a-p/sys/path ... This command looks at the information, if the corresponding information is the device, then congratulations. Otherwise, change the directory. Of course, in this case, the likelihood of success is relatively small.
----------------------------------------------------------------------------------
Udev (Simplified Chinese)
Note: If you are upgrading from DevFS to Udev, please check DevFS to Udev.
This document will introduce some of the new changes in Udev. Starting with version 084, Udev can replace all features of HotPlug and Coldplug. Because of this, the hotplug bag has been removed from the Arch warehouse.
* 1 Important tips
* 2 Basic requirements
* 3 Latest update
* 4 Module Disable list
* 5 Load_modules: Useful start-up parameters
* 6 Known hardware issues
* 7 Auto-loading brings some problems
O 7.1 cpufreq Module
O 7.2 sound problems and some modules that cannot be loaded automatically
o more than 7.3 Similar devices (network cards, sound cards) each start different
* 8 Some known issues caused by compiling your own kernel
O 8.1 udev cannot start
O 8.2 cd/DVD symbol and permissions error
* 9 Udev Tips
O 9.1 automatic loading of USB devices
Important Notes
... Remember that before you load any modules (kernel modules) with udev (whether or not they are loaded automatically at startup), you must set the Mod_autoload option to Yes in/etc/rc.conf or you must manually load these modules. You can modify the modules in rc.conf or use the modprobe command to manually load the modules you need. Another approach is to use hwdetect--modules to generate a modules list of system hardware, and then add this list to rc.conf to have the modules automatically loaded when the system starts.
Basic Requirements
* Kernel: 2.6.15 or later.
* You will not be able to use the DEVFS format device name in Fstab and bootloader settings! For more information, please see Devfs to Udev.
Recent Updates
* Startudev program is removed. If you need to reload Udev rules, use/etc/start_udev.
* Udev replaces the functions of HotPlug and Hwdetect. At the same time we save the Hwdetect and only use it when the MKINITRD program generates INITRD.
* Udev can load multiple modules at the same time, which can speed up the boot speed, however, the result is that she cannot guarantee the order of each load, so when you use a multi-sound card or network card, there will be problems, the problem will be discussed below.
module Disable List
Udev also makes mistakes or loads the wrong modules. To prevent errors from occurring, you can use the module to disable the list. Once the modules are added to the list, either at startup or when the runtime (such as a USB hard drive, etc.) Udev does not load these modules.
Simply add an exclamation point (!) to the module before you rc.conf in the modules to disable the module.
For example
modules= (!modulea!moduleb)
Load_modules: Useful startup Parameters
If you include Load_modules=off in the kernel boot parameters, Udev will stop any automatic loading work. This is useful if there is a problem with the system. If Udev loads the problematic module causing the system to hang or other serious problems, you can use this parameter to disable automatic loading to prevent the problematic module from loading.
Known hardware issues
-The BusLogic device is damaged and causes a crash at startup.
This is a kernel bug that has not been fixed yet.
-PCMCIA readers are considered removable devices.
Add them to/etc/pmount.allow and use Hal's Pmount to read
Some problems caused by automatic loading
Cpufreq Module
We have not found a good way to load different cpufreq controllers, so we removed it from the auto-loading process. If you need to measure CPU frequency, you must explicitly add the appropriate modules in the Rc.conf modules queue.
sound problems and some modules that can't be loaded automatically
Some users trace the problem out of some old parts of the/etc/modprobe.conf, trying to get rid of the old ones and try them out.
Multiple devices of the same type (network card, sound card) are different each time they start
Because Udev loads all modules at the same time, some devices may have different initialization sequences. For example, when there are two network cards at the same time, they always change between eth0 and eth1.
A common workaround is to specify the order in your rc.conf file by modifying the modules queue. The modules in this queue will be loaded by the system before Udev is automatically loaded, so you can control the order in which the modules are loaded at startup.
# load 8139too before E100
modules= (8139too e100)
Another way to resolve the network card is to use the Udev-sanctified method to name each NIC statically. Create the file/etc/udev/rules.d/10-network.rules and then bind the different NIC to a different name on the MAC address:
subsystem== "NET", sysfs{address}== "Aa:bb:cc:dd:ee:ff", name= "Lan0" subsystem== "net", sysfs{address}== "FF:EE:DD:CC: Bb:aa ", name=" Wlan0 "
At the same time, you need to be aware of the following:
* You can obtain the MAC address of the NIC via the following command: Udevinfo-a-p/sys/class/net/< your network card >
* Note that lowercase 16-in MAC addresses are used in Udev rules files because UDEV does not recognize uppercase MAC addresses.
* Some users have problems with old naming methods, such as: eth0, eth1, etc. If this problem occurs, try using a name such as "LAN" or "WLAN".
Be careful not to forget to modify your/dec/rc.conf and other configuration files that are named using ETHX.
some known issues caused by compiling the kernel yourself
Udev cannot start
Make sure your kernel version is greater than or equal to 2.6.15. Older kernels do not have the Uevent functionality required for Udev to automatically load.
CD/DVD symbol and permissions error
If you use the 2.6.15 kernel, you need to install the ABS uevent patch (which extracts some uevent functionality from the 2.6.16 kernel). You can use the ABS command to synchronize the ABS tree, and then you can find the ABS patch under/VAR/ABS/KERNELS/KERNEL26/.
Udev Tips
Automatically load USB devices
kernel== "Sd[a-z", name= "%k", symlink+= "usb%m", group= "users", options= "Last_rule" action== "Add", kernel== "sd[a-z][ 0-9] ", symlink+=" usb%n ", group=" users ", Name="%k "action==" Add ", kernel==" sd[a-z][0-9 ", run+="/bin/mkdir-p/mnt/usb% N "action==" add ", kernel==" sd[a-z][0-9 ", program=="/lib/udev/vol_id-t%N ", result==" Vfat ", run+="/bin/mount-t vfat-o Rw,noauto,sync,dirsync,noexec,nodev,noatime,dmask=000,fmask=111/dev/%k/mnt/usb%n ", OPTIONS=" Last_rule "ACTION==" Add ", kernel==" sd[a-z][0-9] ", run+="/bin/mount-t auto-o Rw,noauto,sync,dirsync,noexec,nodev,noatime/dev/%k/mnt/usb %n ", options=" Last_rule "action==" Remove ", kernel==" sd[a-z][0-9 ", run+="/bin/umount-l/mnt/usb%n "action==" Remove ", kernel== "sd[a-z][0-9", run+= "/bin/rmdir/mnt/usb%n", options= "Last_rule"
Put these Udev rules under/etc/udev/rules.d/. Any file name that ends in. Rules, such as/etc/udev/rules.d/sda.rules.
If you want to establish a/media to/mnt symbolic connection at the same time, you can use the following version:
kernel== "sd[a-z]", name= "%k", symlink+= "Usbhd-%k", group= "users", options= "Last_rule" action== "Add", kernel== " Sd[a-z][0-9] ", symlink+=" Usbhd-%k ", group=" users ", Name="%k "action==" Add ", kernel==" sd[a-z][0-9 ", run+="/bin/mkdir -p/media/usbhd-%k "action==" Add ", kernel==" sd[a-z][0-9] ", run+="/bin/ln-s/media/usbhd-%k/mnt/usbhd-%k "ACTION==" Add ", kernel==" sd[a-z][0-9] ", program=="/lib/udev/vol_id-t%N ", result==" Vfat ", run+="/bin/mount-t vfat-o Rw,noauto, Sync,dirsync,noexec,nodev,noatime,dmask=000,fmask=111/dev/%k/media/usbhd-%k ", OPTIONS=" Last_rule "ACTION==" Add ", kernel== "sd[a-z][0-9]", run+= "/bin/mount-t auto-o rw,noauto,sync,dirsync,noexec,nodev,noatime/dev/%k/media/usbhd- %k ", options=" Last_rule "action==" Remove ", kernel==" sd[a-z][0-9 ", run+="/bin/rm-f/mnt/usbhd-%k "action==" Remove ", kernel== "sd[a-z][0-9]", run+= "/bin/umount-l/media/usbhd-%k" action== "Remove", kernel== "sd[a-z][0-9", RUN+= "/bin/ Rmdir/media/usbhd-%k ", options=" Last_rule "
Attention! If you are using another fixed device (such as a SATA hard drive that you can view from/etc/fstab) is recognized as/DEV/SDX, you must remove your SdX from sd[a-z]. For example, if your SATA hard drive is recognized as/DEV/SDA, you will need to replace all "sd[a-z" with "sd[b-z". It is a good idea to put a number in front of the filename of the rule file (for example: 010.udev.rules), so that udev will read the rule file before reading the Standard Rules. After these rules are set, you do not need to modify the/etc/fstab file. Look at the parameters of the Mount command to modify the attributes such as permissions (you can view the parameters of the Mount command from the forum search and modify them to suit your needs).
Udev under Linux
