Some software that you may want to install later (e.g., various
media players) expect the /dev/cdrom and /dev/dvd symlinks to
exist. Also, it may be convenient to put references to those
symlinks into /etc/fstab
. For each of
your CD-ROM devices, 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.
There are two approaches to creating symlinks. The first one is to use the model name and the serial number, the second one is based on the location of the device on the bus. If you are going to use the first approach, create a file similar to the following:
cat > ${CLFS}/etc/udev/rules.d/82-cdrom.rules << EOF
# Custom CD-ROM symlinks
SUBSYSTEM=="block", ENV{ID_MODEL}=="SAMSUNG_CD-ROM_SC-148F", \
ENV{ID_REVISION}=="PS05", SYMLINK+="cdrom"
SUBSYSTEM=="block", ENV{ID_MODEL}=="PHILIPS_CDD5301", \
ENV{ID_SERIAL}=="5VO1306DM00190", SYMLINK+="cdrom1 dvd"
EOF
Although the examples in this book work properly, be aware that Udev does not recognize the backslash for line continuation. If modifying Udev rules with an editor, be sure to leave each rule on one physical line.
This way, the symlinks will stay correct even if you move the
drives to different positions on the IDE bus, but the /dev/cdrom
symlink won't be created if you
replace the old SAMSUNG CD-ROM with a new drive.
The SUBSYSTEM=="block" key is needed in order to avoid matching
SCSI generic devices. Without it, in the case with SCSI CD-ROMs,
the symlinks will sometimes point to the correct /dev/srX
devices, and sometimes to /dev/sgX
, which is wrong.
The second approach yields:
cat > ${CLFS}/etc/udev/rules.d/82-cdrom.rules << EOF
# Custom CD-ROM symlinks
SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", \
ENV{ID_PATH}=="pci-0000:00:07.1-ide-0:1", SYMLINK+="cdrom"
SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", \
ENV{ID_PATH}=="pci-0000:00:07.1-ide-1:1", SYMLINK+="cdrom1 dvd"
EOF
This way, the symlinks will stay correct even if you replace drives with different models, but place them to the old positions on the IDE bus. The ENV{ID_TYPE}=="cd" key makes sure that the symlink disappears if you put something other than a CD-ROM in that position on the bus.
Of course, it is possible to mix the two approaches.
As explained in Section 7.6,
“Device and Module Handling on a CLFS 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 Networking
Configuration, and sound card configuration can be found in
CBLFS.
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/video
. Figure out the attributes
that identify the device uniquely (usually, vendor and product IDs
and/or serial numbers work):
X
udevadm info -a -p /sys/class/video4linux/video0
Then write rules that create the symlinks, e.g.:
cat > ${CLFS}/etc/udev/rules.d/83-duplicate_devs.rules << EOF
# Persistent symlinks for webcam and tuner
KERNEL=="video*", SYSFS{idProduct}=="1910", SYSFS{idVendor}=="0d81", \
SYMLINK+="webcam"
KERNEL=="video*", SYSFS{device}=="0x036f", SYSFS{vendor}=="0x109e", \
SYMLINK+="tvtuner"
EOF
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.
More information on writing Udev rules can be found in /usr/share/doc/udev-145/index.html
.