Настройка udev rules в linux

Match Keys

The following key names are used to match against device properties. Some of the keys also match against properties of the parent devices in sysfs, and not just the device that has generated the event. If multiple keys are specified in a single rule, all these keys must match.

  • ACTION: Match the name of the event action.
  • DEVPATH: Match the devpath of the event device.
  • KERNEL: Match the name of the event device.
  • NAME: Match the name of a network interface. It can be used if the NAME key was set in one of the preceding rules.
  • SYMLINK: Match the name of the symlink targeting the node. It can be used if a SYMLINK key was set in one of the preceding rules. There can be multiple symlinks but only one needs to match.
  • SUBSYSTEM: Match the subsystem of the event device.
  • TEST{octal mode mask}: Test the existence of a file. You can specify octal mode mask.

Other match keys include DRIVER, ATTR{filename}, KERNELS, SUBSYSTEMS, DRIVERS, ATTRS{filename}, TAGS, ENV{key}, TAG, PROGRAM, and RESULT.

History

udev was introduced in Linux 2.5. The Linux kernel version 2.6.13 introduced or updated a new version of the uevent interface. A system using a new version of udev will not boot with kernels older than 2.6.13 unless udev is disabled and a traditional /dev directory is used for device access.

In April 2012, udev’s codebase was merged into the systemd source tree, making systemd 183 the first version to include udev. In October 2012, Linus Torvalds criticized Kay Sievers’s approach to udev maintenance and bug fixing related to firmware loading, stating:

In 2012, the Gentoo Linux project created a fork of systemd’s udev codebase in order to avoid dependency on the systemd architecture. The resulting fork is called eudev and it makes udev functionality available without systemd. A stated goal of the project is to keep eudev independent of any Linux distribution or init system. The Gentoo project describes eudev as follows:

On May 29, 2014, support for firmware loading through udev was dropped from systemd, as it has been decided that it is kernel’s task to load firmware. Two days later, Lennart Poettering suggested this patch be postponed until kdbus starts to be utilized by udev; at that point, it is planned to switch udev to use kdbus as the underlying messaging system, and to get rid of the userspace-to-userspace netlink-based transport.

Advanced Configuration

Rules

udev provides a set of rules that match against exported values of uevents (events sent by the kernel) and properties of the discovered device. A matching rule will possibly name and create a device node and run configured programs to setup and configure the device.

The rule definitions are stored in two locations:

  1. /lib/udev/rules.d/ — Rules in this directory are installed by certain packages, they generally should not be changed by users;
  2. /etc/udev/rules.d/ — This folder is for end-user specified rules. Any new rules should be added in this directory;

In these directories, multiple rule files (with suffix .rules) are traversed in alphanumerical order. Inside the rules files, udev will find expressions that might match a uevent together with the state to match (is the uevent because a device is added or removed) and the command to execute.

The event matching is based on information such as:

  • The SUBSYSTEM of the uevent (for which type of device is the uevent fired);
  • The ACTION that is taken (add, change, or remove);
  • One or more attributes (through ATTR or ATTRS), such as the device class, vendor or other device information;
  • The kernel-provided name (through KERNEL), such as sd* (for SCSI/SATA disks) or input* (for input devices such as mice and keyboards);
  • One or more environment settings (through ENV), used to send information between multiple rules.

Based on this information, the rule can then state if:

  1. Some information needs to be shared with later events (through environment variables)
  2. Links need to be created in /dev
  3. Commands need to be executed

Udev does this for every rule that matches (it does not stop after the first match) to allow a flexible device management approach.

Persistent device names

The kernel detects devices asynchronously, udev mirrors the kernel’s sysfs filesystem and so the devices are named and numbered in order of detection. So by default udev provides no persistent device names. However there are mechanisms for some device classes to provide these:

Udev creates for storage devices additional symlinks based on the device’s ID, label, UUID and path. See the /dev/disk/by-* directory. So instead of using e.g. the device file /dev/sda use the file /dev/disk/by-label/SOME_LABEL.

The same for input devices in the /dev/input directory.

Using custom rules enables users to create their own device files.

Design

Device drivers are part of the Linux kernel, in which their primary functions include device discovery, detecting device state changes, and similar low-level hardware functions. After loading a device driver into memory from the kernel, detected events are sent out to the userspace daemon udevd. It is the device manager, udevd, that catches all of these events and then decides what shall happen next. For this, udevd has a very comprehensive set of configuration files, which can all be adjusted by the computer administrator, according to their needs.

  • In case a new storage device is connected over USB, udevd is notified by the kernel and itself notifies the udisksd-daemon. That daemon could then mount the file systems.
  • In case a new Ethernet cable is plugged into the Ethernet NIC, udevd is notified by the kernel and itself notifies the NetworkManager-daemon. The NetworkManager-daemon could start dhclient for that NIC, or configure according to some manual configuration.

The complexity of doing so forces application authors to re-implement hardware support logic. Some hardware devices also require privileged helper programs to prepare them for use. These must often be invoked in ways that can be awkward to express with the Unix permissions model (for example, allowing users to join wireless networks only if they are logged into the video console). Application authors resort to using setuid binaries or run service daemons to provide their own access control and privilege separation, potentially introducing security holes each time.

HAL was created to deal with this, but is now deprecated in most Linux distributions.

Конфигурация

RC-сервисы

RC-именем является udev, а не eudev. Оно должно быть зарегистрировано на уровне запуска sysinit.

 * rc-update: udev already installed in runlevel `sysinit'; skipping

Миграция с udev на eudev

Миграция с udev 216 на eudev 1.10-r2 (март 2015) осуществляется прямо:

Если система использует multilib и для старого пакета udev установлен USE-флаг , не забудьте также поменять его:

Файл Переключение с udev на eudev в package.use

# sys-fs/udev abi_x86_32
sys-fs/eudev abi_x86_32

Оставить классическое именование ‘eth0’

Имена сетевых устройств, такие как eth0 или wlan0 и так далее, как предусмотрено ядром, обычно меняются во время загрузки системы (смотрите dmesg) с помощью /lib/udev/rules.d/80-net-name-slot.rules правила udev.

Чтобы сохранить классическое именование это правило может быть перезаписано пустым файлом с таким же именем в каталоге /etc/udev/rules.d:

Также можно добавить в командную строку ядра, изменить политику по умолчанию или добавить собственную.

Использование нового ‘предсказуемого’ именования

Новая схема именования интерфейсов отличается от старой, поэтому символьные ссылки интерфейсов необходимо создать заново. Создайте ссылки на /etc/init.d/net.lo для любых имен интерфейсов, которые необходимо добавить. Не забудьте заменить в нижеприведенных примерах на имена Ethernet-интерфейсов, присутствующих в системе. Узнать, какие интерфейсы присутствуют в системе, можно с помощью команды ifconfig:

Создайте символьные ссылки для существующих сетевых интерфейсов в каталогах /etc/init.d/ и /etc/conf.d/:

Добавьте скрипт(ы) в уровень запуска default, чтобы интерфейс(ы) стартовали автоматически:

Fixing network interfaces

This section provides examples on how to fix network-interfaces if they do not work anymore (or before they stop working before the new udev package has been switched to). It is only applicable to simple setups, like one ethernet and one wifi interface. For more complicated setup (like more ethernet adapters) most users should already know what to do.

Renaming init scripts

If still running the old udev and are ready to enable the new one, then execute:

ID_NET_NAME_MAC=enxd4a8xxxxxxxx
ID_NET_NAME_PATH=enp1s0f1

Take the ID_NET_NAME_PATH-item (here enp1s0f1) and execute

Do the same for any wifi-interfaces.

When already running the new udev and the network is down, execute:

total 0
drwxr-xr-x  2 root root 0 Apr  2 19:42 ./
drwxr-xr-x 49 root root 0 Apr  2 19:42 ../
lrwxrwxrwx  1 root root 0 Apr  2 19:42 enp1s0f1 -> ../../devices/pci0000:00/0000:00:1c.1/0000:02:00.0/net/enp1s0f1/
lrwxrwxrwx  1 root root 0 Apr  2 19:42 lo -> ../../devices/virtual/net/lo/
lrwxrwxrwx  1 root root 0 Apr  2 19:42 sit0 -> ../../devices/virtual/net/sit0/

Look which link points to a pci-device (here enp1s0f1) and execute:

When wifi-interfaces exist do not forget include these interfaces as well.

Installation

ImportantWhen updating udev, check the udev upgrade guide for information that can prevent unbootable systems.

Kernel

udev requires the following kernel options:

KERNEL

General setup  --->
     Configure standard kernel features (expert users)  --->
         Enable deprecated sysfs features to support old userspace tools
         Enable signalfd() system call
Enable the block layer  --->
     Block layer SG support v4
Networking support  --->
    Networking options  --->
        <*> Unix domain sockets
Device Drivers  --->
    Generic Driver Options  --->
        ()  path to uevent helper
         Maintain a devtmpfs filesystem to mount at /dev
    < > ATA/ATAPI/MFM/RLL support (DEPRECATED)  --->
File systems  --->
     Inotify support for userspace
    Pseudo filesystems --->
         /proc file system support
         sysfs file system support

FILE

USE="udev"

Принцип работы

udev запускается как демон и принимает через сокет netlink события uevents от ядра, которые генерируются при инициализации или удалении устройства из системы. Задаваемые пользователем (системой) правила сверяются со свойствами события и соответствующего устройства, и совпавшее правило (которых может быть несколько) может назвать и создать соответствующий файл устройств, а также выполнить другие программы для инициализации и конфигурации устройства. Например, таким образом можно реализовать автоматическое монтирование внешних накопителей при их подключении.

Правила могут сверяться по таким свойствам, как конкретная ядерная подсистема, имя устройства в ядре, физическое расположение устройства, либо по серийному номеру устройства. Правила также могут запрашивать информацию при помощи других программ или указать, что имя устройства всегда будет одним и тем же, вне зависимости от порядка обнаружения устройств системой.

Типичный способ использования udev на Linux-системе — позволить посылать события HAL или DeviceKit, чтобы они произвели последующие зависящие от устройств действия. Например, HAL/DeviceKit может уведомить остальные программы о новом устройстве при помощи широковещательного сообщения в D-Bus. Таким образом, рабочие среды типа GNOME или KDE могут автоматически смонтировать USB-накопитель и открыть файловый менеджер для просмотра его содержимого.

Installation

ImportantWhen updating udev, check the udev upgrade guide for information that can prevent unbootable systems.

Kernel

udev requires the following kernel options:

KERNEL

General setup  --->
     Configure standard kernel features (expert users)  --->
         Enable deprecated sysfs features to support old userspace tools
         Enable signalfd() system call
Enable the block layer  --->
     Block layer SG support v4
Networking support  --->
    Networking options  --->
        <*> Unix domain sockets
Device Drivers  --->
    Generic Driver Options  --->
        ()  path to uevent helper
         Maintain a devtmpfs filesystem to mount at /dev
    < > ATA/ATAPI/MFM/RLL support (DEPRECATED)  --->
File systems  --->
     Inotify support for userspace
    Pseudo filesystems --->
         /proc file system support
         sysfs file system support

FILE

USE="udev"

Migrating from udev to eudev

Migrating from udev 216 to eudev 1.10-r2 (March 2015) is straight forward:

In case the system uses multilib and, for example, has the USE flag active against the older udev package, then don’t forget to change it too:

FILE Switching udev to eudev in package.use

# sys-fs/udev abi_x86_32
sys-fs/eudev abi_x86_32

Use new predictable network interface naming

The new network interface naming convention is not the same. So the symlinks used by netifrc will need to be re-linked. Use /etc/init.d/net.lo as a link target for whatever interface names need to be added. Be sure to replace in the commands below with the Ethernet interface names present on the system. It is possible to discover which interfaces exist by running the ip link command:

Create symbolic links for the existing interfaces in the /etc/init.d/ and /etc/conf.d/ directories:

Add the script(s) to the default runlevel to have the interface(s) start automatically:

udev란 무엇인가요?

/dev 디렉터리

Most Linux users understand that /dev/sda1 is just a fast way of referring to the first partition on the first disk that the kernel found. That’s pretty easy, right?

그런데 USB, IEEE1394, 착탈 가능 PCI 등의 착탈 가능 장치를 고려할 때, 어떤 장치가 첫번째 장치일까요? 얼마나 오래 붙어있을까요? 처음 장치를 떼어냈을 때, 다른 장치에 이름을 어떻게 붙일까요? 트랜잭션에 어떻게 영향을 미칠까요? 누군가의 엄마가 고성능 레이저 프린터(첫번째 프린터에 해당)의 전원 플러그를 뽑기로 해서 인쇄 작업이 거의 맛이 간 매트릭스 프린터로 옮겨간다면 재밌는 일이 되지 않을까요?

장치 관리자에 들어가보겠습니다. (udev와 eudev 같은) 최신 장치 관리자는 다음 역할을 수행합니다:

  • 사용자 영역에서 실행합니다
  • 동적으로 장치 파일en을 만들고 제거합니다
  • 일관성 있는 이름을 제공합니다
  • 사용자 영역 프로그램 인터페이스(API)를 제공합니다.

항상 변경은 장치 구조내에서 일어나며 커널에서는 udev에서 받을 uevent를 쏴보냅니다. udev 는 /etc/udev/rules.d, /run/udev/rules.d, /lib/udev/rules.d 디렉터리에 선언한 규칙을 따릅니다. uevent에 들어간 정보를 기반으로 규칙 또는 실행이 필요한 규칙을 찾고 요구한 동작을 수행합니다. 이 동작은 장치 파일을 만들거나 삭제하는 행위가 될 수 있겠지만 펌웨어 파일을 커널 메모리로 불러오는 작업을 실행하는 동작이 될 수도 있습니다.

What is udev?

The /dev directory

Most Linux users understand that /dev/sda1 is just a fast way of referring to the first partition on the first disk that the kernel found. That’s pretty easy, right?

But consider hotpluggable devices like USB, IEEE 1394, hot-swappable PCI, etc. What is the first device for each of these? And for how long? What will the other devices be named when the first one disappears? How will that affect ongoing transactions? Wouldn’t it be fun if a printing job were suddenly moved from a high-end laser printer to an almost-dead matrix printer just because someone decided to pull the plug on the laser printer (which just happened to be the first printer)?

Enter the device manager. A modern device manager (including udev and eudev) must:

  • Run in userspace;
  • Dynamically create and remove device files;
  • Provide consistent device naming;
  • Provide a userspace application program interface (API).

Every time a change happens within the device structure, the kernel emits a uevent which gets picked up by the device manager. The device manager then follows the rules declared in the /etc/udev/rules.d, /run/udev/rules.d and /lib/udev/rules.d directories. Based on the information contained within the uevent, it finds the rule or rules it needs to trigger and performs the required actions. These actions may involve the creation or deletion of device files, and may also trigger the loading of particular firmware files into kernel memory.

Miscellaneous

NoteThis set of instructions was originally written by Walter Dnes and hosted at his personal website. It was imported to the Gentoo wiki with some editing by Michael Mol per discussion on the gentoo-user mailing list.

mdev unlike udev does not support auto-modules loading. Create files ending with .conf in /etc/modules-load.d/ and put all the modules there that should be loaded (nvidia, wl, etc.) one per line. Customize options via files ending with .conf in /etc/modprobe.d (see man 5 modprobe.d for syntax). It might be necessary to move the module configuration to this location.

mdev -s does not create /dev/mapper nodes. Either manually create them or use dmsetup mknodes from lvm2. It is a good idea to add it after mdev -s in the init script.

Use mouse and keyboard drivers for xorg inputs. Evdev needs udev to be built. Mousedrv (for the mouse driver) may conflict with the synaptic driver when both are loaded.

The Kernel configuration option CONFIG_INPUT_EVDEV not only provides the keyboard and mouse as input device events, it will provide lid and button events to acpid as well.

udev 简介

什么是 udev?

udev 是 Linux2.6 内核里的一个功能,它替代了原来的 devfs,成为当前 Linux 默认的设备管理工具。udev 以守护进程的形式运行,通过侦听内核发出来的 uevent 来管理 目录下的设备文件。不像之前的设备管理工具,udev 在用户空间 (user space) 运行,而不在内核空间 (kernel space) 运行。

使用 udev 的好处:

我们都知道,所有的设备在 Linux 里都是以设备文件的形式存在。在早期的 Linux 版本中,目录包含了所有可能出现的设备的设备文件。很难想象 Linux 用户如何在这些大量的设备文件中找到匹配条件的设备文件。现在 udev 只为那些连接到 Linux 操作系统的设备产生设备文件。并且 udev 能通过定义一个 udev 规则 (rule) 来产生匹配设备属性的设备文件,这些设备属性可以是内核设备名称、总线路径、厂商名称、型号、序列号或者磁盘大小等等。

  • 动态管理:当设备添加 / 删除时,udev 的守护进程侦听来自内核的 uevent,以此添加或者删除 下的设备文件,所以 udev 只为已经连接的设备产生设备文件,而不会在 下产生大量虚无的设备文件。
  • 自定义命名规则:通过 Linux 默认的规则文件,udev 在 /dev/ 里为所有的设备定义了内核设备名称,比如 等等。由于 udev 是在用户空间 (user space) 运行,Linux 用户可以通过自定义的规则文件,灵活地产生标识性强的设备文件名,比如 等等。
  • 设定设备的权限和所有者 / 组:udev 可以按一定的条件来设置设备文件的权限和设备文件所有者 / 组。在不同的 udev 版本中,实现的方法不同,在“如何配置和使用 udev”中会详解。

下面的流程图显示 udev 添加 / 删除设备文件的过程。

图 1. udev 工作流程图:

  • 设备文件:由于本文以较通俗的方式讲解 udev,所以设备文件是泛指在 下,可被应用程序用来和设备驱动交互的文件。而不会特别地区分设备文件、设备节点或者设备特殊文件。
  • devfs:devfs是 Linux 早期的设备管理工具,已经被 udev 取代。
  • sysfs:sysfs是 Linux 2.6 内核里的一个虚拟文件系统 。它把设备和驱动的信息从内核的设备模块导出到用户空间 (userspace)。从该文件系统中,Linux 用户可以获取很多设备的属性。
  • devpath:本文的 devpath是指一个设备在 sysfs文件系统 下的相对路径,该路径包含了该设备的属性文件。udev 里的多数命令都是针对 devpath操作的。例如:sda的 devpath是 ,sda2 的 devpath是 。
  • 内核设备名称:设备在 sysfs里的名称,是 udev 默认使用的设备文件名。

Overview

Unlike traditional Unix systems, where the device nodes in the /dev directory have been a static set of files, the Linux udev device manager dynamically provides only the nodes for the devices actually present on a system. Although devfs used to provide similar functionality, Greg Kroah-Hartman cited a number of reasons for preferring udev over devfs:

  • udev supports persistent device naming, which does not depend on, for example, the order in which the devices are plugged into the system. The default udev setup provides persistent names for storage devices. Any hard disk is recognized by its unique filesystem id, the name of the disk and the physical location on the hardware it is connected to.
  • udev executes entirely in user space, as opposed to devfs’s kernel space. One consequence is that udev moved the naming policy out of the kernel and can run arbitrary programs to compose a name for the device from the device’s properties, before the node is created; there, the whole process is also interruptible and it runs with a lower priority.

The udev, as a whole, is divided into three parts:

  • Library libudev that allows access to device information; it was incorporated into the systemd 183 software bundle.
  • User space daemon udevd that manages the virtual /dev.
  • Administrative command-line utility udevadm for diagnostics.

The system gets calls from the kernel via netlink socket. Earlier versions used hotplug, adding a link to themselves in /etc/hotplug.d/default with this purpose.

udev 208 to 216

The following special attention is required:

  • Since this version, kernel settings and are mandatory. Kernel setting is recommended for amd64/ia64/x86, for example, keyboard rules.
  • File /lib/udev/rules.d/80-net-name-slot.rules was replaced with /lib/udev/rules.d/80-net-setup-link.rules. If currently using an empty (or single-comment) /etc/udev/rules.d/80-net-name-slot.rules to disable predictable network interface names, the 80-net-setup-link.rules should now be used. For example:

This keeps the override both pre- and post-upgrade; then run:

once the upgrade has been made. The hardlink can be made, in order to protect against not noticing the upgrade in a busy or non-professional situation.

  • However, 80-net-setup-link.rules is only a trigger for the actual configuration file 99-default.link at /lib/systemd/network/ which can be overrided at /etc/systemd/network/
  • The most reliable way of disabling the new network interface scheme is still the kernel bootline parameter:

Обзор

udev состоит из нескольких сервисов ядра и демона (процесса) udevd. Ядро сообщает демону udevd о наступлении определённого события. Сам демон udevd реагирует на наступившее событие через actions («действия»). Информация о событии поступает от ядра. Все действия происходят в пользовательском окружении. Можно ли сделать так, чтобы от ядра передавалась только определенная информация о событии ? Можно настраивать действия на наступившее событие через «rules» («правила»).

Демон udevd запускается скриптом /etc/rcS.d/udev. Файл конфигурации находится в /etc/udev/udev.conf. Файл правил для более полной настройки демона udevd лежит в /etc/udev/rules.d. Файлы находящиеся в данной директории оканчивающиеся на «.rules» парсятся в алфавитном порядке. При изменении конфигурационного файла или файла правил, демон udevd следует перезапускать.

Множество файлов, находящихся в директории /etc/udev/rules.d, ссылаются на другие файлы. Можно предположить, что при редактировании файлов правил, текстовый редактор сделает работоспособные резервные копии, которые можно будет использовать при следующем запуске udevd. Поскольку имена ссылок могут отличаться от имён исходных файлов, они могут быть упорядочены без опасений.

udev был создан для реагирования на события типа «горячего подключения». Большая часть документации касается создания файлов устройств для новых физических устройств появившихся в системе. Однако udev не является узкоспециализированным. Он может запускать любую команду пользовательского режима в ответ на обнаружение нового устройства или любого другого события, полученного от ядра.

Когда работает udevd:

  1. при загрузке он парсит все конфигурационные файлы и файлы правил и создаёт в памяти базу данных правил
  2. при появлении события. Он проверяет свою базу данных правил и осуществляет соответствующие действия.

Правила

Правила для правил:

  1. правила пишутся в одну строку. Строка может быть разбита символом \ после которого сразу идёт символ новой строки (клавиша Enter)
  2. правила состоят из «matches» (соответствий) и «actions» (действий)
  3. matches и actions — это триплеты «key»(ключ) «operator»(оператор) «value» (значение)
  4. matches (соответствия) имеют оператор == или !=
  5. actions (действия) имеют оператор = (оператор присваивания)
  6. соответствия (matches) проверяют один или более атрибутов события для определения необходимости выполнения действия.
  7. действия (actions) указывают на то, что должно происходить
  8. пример соответствия (match): BUS=="usb"

  9. пример действия (action): NAME="mydev"

  10. пример правила (rule):

    KERNEL=="sd*|dasd*", ENV{ID_SERIAL}=="?*", \
            SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}-part%n"
  11. все подходящие правила будут применены
  12. предшествующие правила имеют приоритет над последующими, поэтому помещайте свои изменения в список файлов, находящийся в rules.d
  13. действия (action) вида key=»value» перезаписываются
  14. действия (action) вида key+=»value» добавляются к существующим. Например, SYMLINK+="foo" означает, что в дополнение к любым другим symlinks («симлинкс»), которые должны быть выполнены для данного события, также следует выполнить foo. («фуу»)

Множество правил

Правила для множества правил:

Все правила находятся в одном пространстве, хотя и располагаются в нескольких файлах.

В этом пространстве имеется возможность создавать метки и с их помощью пропускать некоторое количество правил, в зависимости от условия. Это осуществляется с помощью действия («action») GOTO

Также существует ещё один тип правил, называемый меткой. Например, LABEL=»persistent_storage_end». Этот тип используется в обычных правилах с действием «GOTO»(«гоуту»), например
ACTION!=»add», GOTO=»persistent_storage_end»

Обратите внимание, что ACTION (действие) является атрибутом события и используется в качестве предусловия для выполнения действия GOTO.

Использование GOTO для «прыжков» в рамках одного файла вполне нормально. Если же Вы используете GOTO для «прыжков» между файлами, то Вам следует думать о том, что порядок файлов может быть изменён

Не возвращайтесь обратно на «метку». Это может привести к бесконечному циклу.

Вы можете установить переменную среды ENV в ранних правилах, а затем ссылаться на неё в последующих.

Существуют средства для динамического создания правил. Пример смотрите z45_persistent-net-generator.rules

Troubleshooting

Log monitor messages

To log all message when udevadm monitor is ran, modify the following configuration file:

FILE

udev_monitor="YES"

It will create the new log file located at /run/udev/udevmonitor.log

Debug mode

Enabling debug mode will output more log messages:

FILE

udev_debug="YES"

Set the logging priority:

FILE

udev_log="debug"

The log file /run/udevdebug.log will be created but no messages will be logged to it. The most recent versions of udev will log all messages to dmesg.

Missing device files /dev/null and /dev/console

Some udev versions need the /dev/null and /dev/console files in order to work properly, but can not create them on their own. To manually create these files for udev run the following commands with root privileges:

NIC assigned eth0, but is moved to eth1

Those having dual network cards on their motherboards may run into a situation where ifconfig may show no eth0 or eth1. dmesg may show their NIC detected as eth0, and later moved to eth1. Performing a ifconfig -a will also show the NIC as eth1. This is caused by using the kernel assigned names in the first place. Users should write custom rules like /etc/udev/rules.d/70-my-network.rules to use free names like lan0 or wireless0 or use predictable interface names (which have been enabled by default since udev version 197).

Remember to also remove old files from old versions of udev:

Also make sure not to pass on the kernel commandline. This setting would disable the predictable interface names feature of udev altogether.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *