Udev, par défaut, nomme les périphériques réseaux à partir des données du Firmware/BIOS ou de leurs caractéristiques physiques comme leur bus, leur slot ou leur adresse MAC. Le but de cette convention de nommage est de s'assurer que les périphériques réseaux sont nommés de façon cohérente et non en fonction de l'heure à laquelle la carte réseau a été trouvée. Par exemple, sur un ordinateur possédant deux cartes réseaux Intel et Realtek, il se peut que la carte réseau Intel soit nommée eth0 et la Realtek soit nommée eth1. Dans certains cas, au redémarrage, les cartes sont numérotées en sens inverse.
Avec la nouvelle règle de nommage, les noms des cartes réseaux ressembleraient en général à quelque chose comme enp5s0 ou wlp3s0. Si cette convention de nommage ne vous plaît pas, vous pouvez implémenter la convention de nommage traditionnelle ou une personnalisée.
Vous pouvez rétablir la règle de nommage traditionnelle qui
utilise eth0, eth1, etc en ajoutant net.ifnames=0
à la ligne de
commandes du noyau. Ceci est surtout adapté aux systèmes n'ayant
qu'un périphérique ethernet du même type. Les portables ont
souvent plusieurs ports ethernet appelés eth0 et wlan0, ils sont
donc éligibles à cette méthode. La ligne de commandes se passe
dans le fichier de configuration de GRUB. Voir Section 10.4.4,
« Créer le fichier de configuration de GRUB ».
Vous pouvez personnaliser les règles de nommage en créant des règles udev personnalisées. Un script est inclus pour générer les règles initiales. Générez ces règles en lançant :
bash /usr/lib/udev/init-net-rules.sh
Maintenant, lisez le fichier /etc/udev/rules.d/70-persistent-net.rules
pour
trouver le nom affecté à une carte réseau :
cat /etc/udev/rules.d/70-persistent-net.rules
Dans certains cas, comme lorsqu'une adresse MAC est affectée manuellement à une carte réseau ou dans un environnement virtuel tel que Qemu ou Xen, il se peut que le fichier des règles du réseau n'ait pas été généré car les adresses ne sont pas affectées de façon cohérente. Dans ces cas-là, vous ne pouvez pas utiliser cette méthode.
Le fichier commence par un bloc en commentaire suivi de deux lignes pour chaque NIC. La première ligne d'un NIC est une description commentée indiquant ses ID matériels (comme ses ID PCI de fabricant et de périphérique si c'est une carte PCI), avec le pilote entre parenthèses, si le pilote est détecté. Ni l'ID matériel ni le pilote ne sont utilisés pour déterminer le nom à donner à une interface ; ces informations ne sont présentes qu'à titre informatif. La deuxième ligne est la règle udev correspondant à cette NIC et qui lui affecte un nom.
Toutes les règles udev se composent de clés séparées par des virgules et éventuellement des espaces. Les clés de cette règle et l'explication de chacune sont :
SUBSYSTEM=="net"
— Ceci dit à
udev d'ignorer les périphériques n'étant pas des cartes
réseaux.
ACTION=="add"
— Ceci dit à
udev d'ignorer la règle pour un uevent autre qu'un ajout
(les uevents « remove » et « change »
se produisent aussi mais il n'est pas utile de renommer les
interfaces réseaux).
DRIVERS=="?*"
— Ceci existe
pour que udev ignore les sous-interfaces VLAN ou les ponts
(ces interfaces n'ayant pas de pilote). Ces sous-interfaces
sont ignorées car le nom qui leur serait affecté entrerait
en conflit avec leurs périphériques parents.
ATTR{address}
- La valeur de
cette clé est l'adresse MAC de la NIC.
ATTR{type}=="1"
— Ceci
garantit que la règle ne corresponde qu'à l'interface
primaire au cas où certains pilotes sans fil créent
plusieurs interfaces virtuelles. Les interfaces secondaires
sont ignorées pour la même raison que l'on évite les
sous-interfaces VLAN et les ponts : il y aurait
conflit de noms.
NAME
— La valeur de cette clé
est le nom donné par udev à cette interface.
La valeur de NAME
est la partie
importante. Assurez-vous de connaître le nom affecté à chacune de
vos cartes réseaux avant de continuer, et d'utiliser cette valeur
NAME
quand vous créez les fichiers
de configuration ci-dessous.
Certains logiciels que vous pourriez vouloir installer
ultérieurement (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
d'insérer 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 « 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 « 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 possédez.
Il existe des avantages pour 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 ou les fentes par lesquels ils sont branchés) changent, 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 « 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 remplaciez par un périphérique différent avec les mêmes capacités et qui serait monté sur les mêmes connecteurs, vous devriez utiliser le mode « chemin ».
Si les deux types de changement sont possibles avec votre lecteur, choisissez un mode basé sur le type de changement que vous pensez rencontrer le plus fréquemment.
Les périphériques externes (par exemple un lecteur CD connecté en USB) ne devraient pas utiliser la méthode des chemins, car chaque fois que le périphérique est monté sur un nouveau port, son chemin physique change. 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, alors, pour celles appropriées au périphérique CD-ROM,
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 « id » utilisera la valeur ID_SERIAL si elle existe et n'est pas vide, sinon il utilisera une combinaison d'ID_MODEL et d'ID_REVISION. Le mode « chemin » utilisera la valeur d'ID_PATH.
Si le mode par défaut ne convient pas à votre situation, vous
pouvez faire la modification suivante du fichier /etc/udev/rules.d/83-cdrom-symlinks.rules
, comme
suit, (où mode
est soit
« by-id » soit « by-path ») :
sed -e 's/"write_cd_rules"/"write_cd_rules mode
"/' \
-i /etc/udev/rules.d/83-cdrom-symlinks.rules
Remarquez qu'il n'est pas nécessaire de créer les fichiers de
règles 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 supposons 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 pointent 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é à la Section 9.3,
« Manipulation des périphériques et modules »,
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 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ée dans Section 9.5,
« Configuration générale du réseau », 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 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 certains des liens symboliques /dev/tvtuner
et /dev/webcam
pointent toujours vers le bon
périphérique.