Certains logiciels que vous pourriez vouloir installer plus tard
(comme divers lecteurs multimédias) s'attendent à ce que les liens
symboliques /dev/cdrom
et
/dev/dvd
existent et pointent vers le
lecteur CD-ROM ou DVD-ROM. De plus, il peut être pratique de mettre
des références à ces liens symboliques dans /etc/fstab
. Udev est fourni avec un script qui
générera des fichiers de règles pour créer ces liens symboliques
pour vous, selon les possibilités de chaque périphérique, mais vous
devez décider lequel des deux modes opératoires vous souhaitez que
le script utilise.
Tout d'abord, le script peut opérer en mode « selon-le-chemin » (utilisé par défaut pour les périphériques USB et FireWire), où les règles qu'il crée dépendent du chemin physique vers le lecteur CD ou DVD. Ensuite, il peut opérer en mode « selon-l-id » (par défaut pour les périphériques IDE et SCSI), où les règles qu'il crée dépendent des chaînes d'identification contenues dans le lecteur CD ou DVD lui-même. Le chemin est déterminé par le script path_id d'Udev, et les chaînes d'identification sont lues à partir du matériel par ses programmes ata_id ou scsi_id, selon le type de périphérique que vous avez.
Il y a des avantages dans chaque approche ; la bonne approche à utiliser dépendra des types de changements de périphérique qui peuvent se produire. Si vous vous attendez à ce que le chemin physique vers le périphérique (c'est-à-dire, les ports et/ou les slots par lesquels ils sont branchés) change, par exemple parce que vous envisagez de déplacer le lecteur sur un port IDE différent ou un connecteur USB différent, alors vous devriez utiliser le mode « par-l-id ». D'un autre côté, si vous vous attendez à ce que l'identification du périphérique change, par exemple parce qu'il peut mourir et que vous le remplaceriez par un périphérique différent avec les mêmes possibilités et qui serait monté sur les mêmes connecteurs, vous devriez utiliser le mode « par-chemin ».
Si les deux types de changement sont possibles avec votre lecteur, choisissez un mode basé sur le type de changement que vous pensez avoir plus fréquemment.
Les périphériques externes (par exemple un lecteur CD connecté en USB) ne devraient pas utiliser la méthode by-path, car chaque fois que le périphérique est monté sur un nouveau port, son chemin physique changera. Tous les périphériques connectés en externe auront ce problème si vous écrivez des règles Udev pour les reconnaître par leur chemin physique , le problème ne concerne pas que les lecteurs CD et DVD.
Si vous souhaitez voir les valeurs que les scripts Udev
utiliseront, et pour le périphérique CD-ROM approprié, trouvez le
répertoire correspondant sous /sys
(cela peut être par exemple /sys/block/hdd
) et lancez une commande
ressemblant à ce qui suit :
udevadm test /sys/block/hdd
Regardez les lignes contenant la sortie des divers programmes *_id. Le mode « par-l-id » utilisera la valeur ID_SERIAL si elle existe et qu'elle n'est pas vide, sinon il utilisera une combinaison de ID_MODEL et de ID_REVISION. Le mode « by-path » utilisera la valeur de ID_PATH.
Si le mode par défaut ne convient pas à votre situation, vous
pouvez faire la modification suivante du fichier /lib/udev/rules.d/75-cd-aliases-generator.rules
,
comme suit, (où mode
est
soit « par-l-id » soit
« par-chemin ») :
sed -i -e 's/write_cd_rules/& mode
/' \
/lib/udev/rules.d/75-cd-aliases-generator.rules
Remarquez qu'il n'est pas nécessaire de créer les fichiers de règle
ou les liens symboliques à ce moment puisque vous avez monté en
bind le répertoire /dev
du système
hôte dans le système LFS, et nous assumons que les liens
symboliques existent sur l'hôte. Les règles et les liens
symboliques seront créés la première fois que vous démarrerez votre
système LFS.
Cependant, si vous avez plusieurs lecteurs CD-ROM, les liens
symboliques générés à ce moment peuvent pointer vers des
périphériques différents de ceux vers lesquels ils pointent sur
votre hôte, car les périphériques ne sont pas découverts dans un
ordre prévisible. Les affectations créées quand vous démarrerez
pour la première fois le système LFS seront stables, donc cela
n'est un problème que si vous avez besoin que les liens symboliques
sur les deux systèmes poinjent vers le même périphérique. Si tel
est le cas, inspectez (et éditez peut-être) le fichier /etc/udev/rules.d/70-persistent-cd.rules
généré
après le démarrage pour vous assurer que les liens symboliques
affectés correspondent à ce dont vous avez besoin.
Comme expliqué dans
Section 7.9, « Gestion des périphériques et modules sur
un système LFS », l'ordre dans lequel les périphériques
ayant la même fonction apparaissent dans /dev
est essentiellement aléatoire. Par exemple
si vous avez une webcam en USB et un tunner TV, parfois
/dev/video0
renvoie à la webcam, et
/dev/video1
renvoie au tuner, et
parfois après un redémarrage l'ordre s'inverse. Pour toutes les
classes de matériel sauf les cartes son et les cartes réseau, ceci
peut se corriger en créant des règles udev pour des liens
symboliques constants personnalisés. Le cas des cartes réseau est
couvert de façon séparé dans Section 7.13,
« Configurer le script network », et vous pouvez
trouver la configuration des cartes son dans
BLFS.
Pour chacun des périphériques susceptibles d'avoir ce problème
(même si le problème n'apparaît pas dans votre distribution Linux
actuelle), trouvez le répertoire correspondant sous /sys/class
ou /sys/block
. Pour les périphériques vidéo, cela
peut être /sys/class/video4linux/video
. Calculez les attributs
qui identifient de façon unique un périphérique (normalement basé
sur l'ID du fabricant et du produit et/ou les numéros de
série) :
X
udevadm info -a -p /sys/class/video4linux/video0
Puis, écrivez des règles qui créent les liens symboliques, comme :
cat > /etc/udev/rules.d/83-duplicate_devs.rules << "EOF"
# Persistent symlinks for webcam and tuner
KERNEL=="video*", ATTRS{idProduct}=="1910", ATTRS{idVendor}=="0d81", \
SYMLINK+="webcam"
KERNEL=="video*", ATTRS{device}=="0x036f", ATTRS{vendor}=="0x109e", \
SYMLINK+="tvtuner"
EOF
Il en résulte que les périphériques /dev/video0
et /dev/video1
renvoient encore de manière aléatoire
au tuner et à la webcam (et donc ne devrait jamais être utilisé
directement), mais il y a des liens smboliques /dev/tvtuner
et /dev/webcam
qui pointent toujours vers le bon
périphérique.