User:SwifT/Wikified but not merged documents/Udev guide

From Gentoo Wiki
Jump to:navigation Jump to:search

What is udev?

The /dev Directory

When Linux-users talk about the hardware on their system in the vicinity of people who believe Linux is some sort of virus or brand of coffee, the use of "slash dev slash foo" will return a strange look for sure. But for the fortunate user (and that includes you) using /dev/sda1 is just a fast way of explaining that we are talking about the primary master SATA, first partition. Or aren't we?

We all know what a device file is. Some even know why device files have special numbers when we take a closer look at them when we issue ls -l in /dev . But what we always take for granted is that the primary SATA disk is referred to as /dev/sda . You might not see it this way, but this is a flaw by design.

Think about hotpluggable devices like USB, IEEE1394, hot-swappable PCI, ... What is the first device? 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 that a printing job is suddenly moved from your supernew laserprinter to your almost-dead matrix printer because your mom decided to pull the plug of the laserprinter which happened to be the first printer?

Enter udev . The goals of the udev project are both interesting and needed:

  • Runs in userspace
  • Dynamically creates/removes device files
  • Provides consistent naming
  • Provides a user-space API

Every time a change happens within the device structure, the kernel emits a uevent which gets picked up by udev. udev then follows the rules as 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 can be creating or deleting device files, but can also trigger the loading of particular firmware files into the kernel memory.

Using udev on Gentoo


udev is meant to be used in combination with a 3.x kernel (like gentoo-sources with the default 13.0 profile). If you're using such a kernel then you just should have no issues whatsoever with using udev as the necessary support is built-in in all stable sys-apps/baselayout versions. Normally, udev should already be installed on your system, but if this is not the case, then it is easy to install:

CODE Installing udev
# emerge udev

Kernelwise, be sure to activate the following options:

CODE Required kernel options
General Setup --->
  ## (Make sure the following item is *not* enabled)
  [ ] Enable deprecated sysfs features to support old userspace tools

File Systems --->
  [*] Inotify support for userspace
  Pseudo filesystems --->
    [*] Virtual memory file system support (former shm fs)

Device Drivers --->
  ## (Make sure the following item is *not* enabled)
  ## (This is *absolutely* necessary for /dev to populate)
  Generic Driver Options --->
    [*] Maintain a devtmpfs filesystem to mount at /dev (NEW)

If you use sys-kernel/genkernel , you don't need to do anything special. Genkernel sets up udev by default. You can also try sys-kernel/dracut which is quite well integrated into Gentoo.

Resources & Acknowledgements

Documentation for using the predictable network interface names introduced in 197, replacing the now deleted rule_generator's /etc/udev/rules.d/70-persistent-net.rules

Fork of the systemd git tree without systemd itself at github, with aims like longterm stable API, more POSIX than GNU, aimed much for minimal embedded but works on anything else too. You decide if it's up to date by looking at the repository's history, since this documentation might not be.

Known problems

Stale 70-persistent-net.rules (or other network rules) in /etc/udev/rules.d can prevent the predictable network naming from being enabled. Both 70-persistent-net.rules and 70-persistent-cd.rules are from the now deleted rule_generator

Init script called 'udev-postmount' should be removed from runlevels if it's still there.


We would like to thank the following authors and editors for their contributions to this guide:

  • Sven Vermeulen
  • Gregorio Guidi
  • nightmorph