Beyond Linux® From Scratch - Version 7.7

Chapter 3. After LFS Configuration Issues

About Devices

Although most devices needed by packages in BLFS and beyond are set
up properly by udev using the
default rules installed by LFS in /etc/udev/rules.d, there are cases where the rules
must be modified or augmented.

Multiple Sound Cards

If there are multiple sound cards in a system, the "default" sound
card becomes random. The method to establish sound card order
depends on whether the drivers are modules or not. If the sound
card drivers are compiled into the kernel, control is via kernel
command line parameters in /boot/grub/grub.cfg. For example, if a system has
both an FM801 card and a SoundBlaster PCI card, the following can
be appended to the command line:

snd-fm801.index=0 snd-ens1371.index=1

If the sound card drivers are built as modules, the order can be
established in the /etc/modprobe.conf
file with:

options snd-fm801 index=0
options snd-ens1371 index=1

USB Device
Issues

USB devices usually have two kinds of device nodes associated with
them.

The first kind is created by device-specific drivers (e.g.,
usb_storage/sd_mod or usblp) in the kernel. For example, a USB mass
storage device would be /dev/sdb, and a USB printer would be
/dev/usb/lp0. These device nodes exist only when the
device-specific driver is loaded.

The second kind of device nodes (/dev/bus/usb/BBB/DDD, where BBB is
the bus number and DDD is the device number) are created even if
the device doesn't have a kernel driver. By using these "raw" USB
device nodes, an application can exchange arbitrary USB packets
with the device, i.e., bypass the possibly-existing kernel driver.

Access to raw USB device nodes is needed when a userspace program
is acting as a device driver. However, for the program to open the
device successfully, the permissions have to be set correctly. By
default, due to security concerns, all raw USB devices are owned by
user root and group usb, and have 0664 permissions (the read access
is needed, e.g., for lsusb to work and for programs to access USB
hubs). Packages (such as SANE and libgphoto2) containing userspace
USB device drivers also ship udev rules that change the permissions
of the controlled raw USB devices. That is, rules installed by SANE
change permissions for known scanners, but not printers. If a
package maintainer forgot to write a rule for your device, report a
bug to both BLFS (if the package is there) and upstream, and you
will need to write your own rule.

There is one situation when such fine-grained access control with
pre-generated udev rules doesn't work. Namely, PC emulators such as
KVM, QEMU and VirtualBox use raw USB device nodes to present
arbitrary USB devices to the guest operating system (note: patches
are needed in order to get this to work without the obsolete
/proc/bus/usb mount point described below). Obviously, maintainers
of these packages cannot know which USB devices are going to be
connected to the guest operating system. You can either write
separate udev rules for all needed USB devices yourself, or use the
default catch-all "usb" group, members of which can send arbitrary
commands to all USB devices.

Before Linux-2.6.15, raw USB device access was performed not with
/dev/bus/usb/BBB/DDD device nodes, but with /proc/bus/usb/BBB/DDD
pseudofiles. Some applications (e.g., VMware Workstation) still use
only this deprecated technique and can't use the new device nodes.
For them to work, use the "usb" group, but remember that members
will have unrestricted access to all USB devices. To create the
fstab entry for the obsolete usbfs filesystem:

usbfs /proc/bus/usb usbfs devgid=14,devmode=0660 0 0

Note

Adding users to the "usb" group is inherently insecure, as they
can bypass access restrictions imposed through the
driver-specific USB device nodes. For instance, they can read
sensitive data from USB hard drives without being in the "disk"
group. Avoid adding users to this group, if you can.

Udev Device Attributes

Fine-tuning of device attributes such as group name and permissions
is possible by creating extra udev
rules, matching on something like this. The vendor and product can
be found by searching the /sys/devices directory entries or using
udevadm info after
the device has been attached. See the documentation in the current
udev directory of /usr/share/doc for details.

Note

The above line is used for descriptive purposes only. The scanner
udev rules are put into place
when installing SANE-1.0.24.

Devices for Servers

In some cases, it makes sense to disable udev completely and create static devices.
Servers are one example of this situation. Does a server need the
capability of handling dynamic devices? Only the system
administrator can answer that question, but in many cases the
answer will be no.

If dynamic devices are not desired, then static devices must be
created on the system. In the default configuration, the
/etc/rc.d/rcS.d/S10udev boot script
mounts a tmpfs partition over the
/dev directory. This problem can be
overcome by mounting the root partition temporarily:

Warning

If the instructions below are not followed carefully, your system
could become unbootable.

At this point, the system will use static devices upon the next
reboot. Create any desired additional devices using mknod.

If you want to restore the dynamic devices, recreate the
/etc/rc.d/rcS.d/{S10udev,S50udev_retry} symbolic
links and reboot again. Static devices do not need to be removed
(console and null are always needed) because they are covered by
the tmpfs partition. Disk usage for
devices is negligible (about 20–30 bytes per entry.)