Linux From Scratch - Version 7.1

Chapter 7. Setting Up System Bootscripts

7.5.
Creating Custom Symlinks to Devices

7.5.1. CD-ROM symlinks

Some software that you may want to install later (e.g., various
media players) expect the /dev/cdrom
and /dev/dvd 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 /etc/fstab. 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.

First, the script can operate in “by-path” 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
“by-id” mode (default for
IDE and SCSI devices), where the rules it creates depend on
identification strings stored in the CD or DVD device itself. The
path is determined by Udev's path_id script, and the
identification strings are read from the hardware by its
ata_id or
scsi_id programs,
depending on which type of device you have.

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 “by-id” 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 “by-path”
mode.

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.

Important

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.

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 /sys (e.g., this can be
/sys/block/hdd) and run a command
similar to the following:

udevadm test /sys/block/hdd

Look at the lines containing the output of various *_id programs.
The “by-id” 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
“by-path” mode will use the
ID_PATH value.

If the default mode is not suitable for your situation, then the
following modification can be made to the /lib/udev/rules.d/75-cd-aliases-generator.rules
file, as follows (where mode is one of “by-id” or “by-path”):

Note that it is not necessary to create the rules files or symlinks
at this time, because you have bind-mounted the host's /dev 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.

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 /etc/udev/rules.d/70-persistent-cd.rules file
after booting, to make sure the assigned symlinks match what you
need.

7.5.2. Dealing with duplicate devices

As explained in Section 7.4,
“Device and Module Handling on an LFS System”, the
order in which devices with the same function appear in
/dev is essentially random. E.g., if
you have a USB web camera and a TV tuner, sometimes /dev/video0 refers to the camera and /dev/video1 refers to the tuner, and sometimes
after a reboot the order changes to the opposite one. 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 Section 7.2,
“General Network Configuration”, and sound card
configuration can be found in
BLFS.

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 /sys/class or /sys/block. For video devices, this may be
/sys/class/video4linux/videoX. Figure out the attributes
that identify the device uniquely (usually, vendor and product IDs
and/or serial numbers work):

The result is that /dev/video0 and
/dev/video1 devices still refer
randomly to the tuner and the web camera (and thus should never be
used directly), but there are symlinks /dev/tvtuner and /dev/webcam that always point to the correct
device.