udev (Français)
udev est une interface entre le noyau et l'utilisateur qui permet au système d'exploitation d'enregistrer la gestion des événements en espace utilisateur. Les événements décodés par le daemon d'udev sont en effet principalement déclenchés par le noyau Linux en réponse à des signaux physiques comme la connexion d'un périphérique plug-and-play. De ce point de vue, la principale fonction d'udev est la détection de périphérique et la connexion de ports intelligents, ainsi que la restitution du contrôle au noyau Linux, par ex. le chargement de modules ou de firmwares vers le noyau. Un autre élément de cette détection consiste à ajuster les autorisations de l'appareil pour qu'il soit accessible aux utilisateurs et groupes non root.
En tant que successeur de devfsd et de hotplug, udev gère également les nœuds de périphériques dans le répertoire /dev en les ajoutant, en créant des liens symboliques et en les renommant. udev remplace les fonctionnalités de hotplug et de hwdetect.
udev traite des événements distincts simultanément (en parallèle), ce qui entraîne une amélioration potentielle des performances par rapport aux anciens systèmes. En même temps, cela peut compliquer l'administration du système, car, par exemple, l'ordre de chargement des modules du noyau n'est pas préservé d'un démarrage à l'autre. Si la machine possède plusieurs périphériques de type bloc, cela peut se manifester sous la forme de nœuds de périphérique changeant de désignation après le redémarrage. Par exemple, si la machine possède deux disques durs, /dev/sda peut devenir /dev/sdb au prochain démarrage. Poursuivez votre lecture pour plus d'informations à ce sujet.
Installation
udev fait partie de systemd et est donc installé par défaut. Consultez systemd-udevd.service(8) pour plus d'informations.
À propos des règles udev
Les règles udev écrites par l'administrateur se trouvent dans /etc/udev/rules.d/, leur nom de fichier doit se terminer par .rules. Les règles udev fournies avec divers paquets se trouvent dans /usr/lib/udev/rules.d/. S'il y a deux fichiers du même nom sous /usr/lib et /etc, celui de /etc est prioritaire.
Pour en savoir plus sur les règles udev, reportez-vous au manuel udev(7). Consultez également Writing udev rules et des exemples pratiques sont fournis dans le guide : Rédaction des règles udev - Exemples.
Exemple de règle udev
Voici un exemple de règle qui crée un lien symbolique /dev/video-cam lorsqu'une webcam est connectée.
Disons que cette caméra est actuellement connectée et a été chargée avec le nom de périphérique /dev/video2. La raison de l'écriture de cette règle est qu'au prochain démarrage, le périphérique pourrait apparaître sous un nom différent, comme /dev/video0.
$ udevadm info --attribute-walk --path=$(udevadm info --query=path --name=/dev/video2)
Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices.
It prints for every device found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:04.1/usb3/3-2/3-2:1.0/video4linux/video2':
KERNEL=="video2"
SUBSYSTEM=="video4linux"
...
looking at parent device '/devices/pci0000:00/0000:00:04.1/usb3/3-2/3-2:1.0':
KERNELS=="3-2:1.0"
SUBSYSTEMS=="usb"
...
looking at parent device '/devices/pci0000:00/0000:00:04.1/usb3/3-2':
KERNELS=="3-2"
SUBSYSTEMS=="usb"
ATTRS{idVendor}=="05a9"
ATTRS{manufacturer}=="OmniVision Technologies, Inc."
ATTRS{removable}=="unknown"
ATTRS{idProduct}=="4519"
ATTRS{bDeviceClass}=="00"
ATTRS{product}=="USB Camera"
...
Pour identifier la webcam, à partir du périphérique video4linux, nous utilisons KERNEL=="video2" et SUBSYSTEM=="video4linux", puis nous remontons deux niveaux au-dessus, nous faisons correspondre la webcam en utilisant les identifiants du fournisseur et du produit du parent usb SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9" et ATTRS{idProduct}=="4519".
Nous sommes maintenant en mesure de créer une règle de correspondance pour ce périphérique comme suit :
/etc/udev/rules.d/83-webcam.rules
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", SYMLINK+="video-cam"
Nous créons ici un lien symbolique en utilisant SYMLINK+="video-cam" mais nous pourrions facilement définir l'utilisateur OWNER="john" ou le groupe en utilisant GROUP="video" ou définir les autorisations en utilisant MODE="0660".
Si vous avez l'intention d'écrire une règle pour faire quelque chose lorsqu'un périphérique est retiré, sachez que les attributs du périphérique peuvent ne pas être accessibles. Dans ce cas, vous devrez travailler avec des variables d'environnement de périphérique prédéfinies. Pour surveiller ces variables d'environnement, exécutez la commande suivante tout en débranchant votre périphérique :
$ udevadm monitor --environment --udev
Dans le résultat de cette commande, vous consulterez des paires de valeurs telles que ID_VENDOR_ID et ID_MODEL_ID, qui correspondent aux attributs précédemment utilisés idVendor et idProduct. Une règle qui utilise les variables d'environnement du périphérique au lieu des attributs du périphérique peut ressembler à ceci :
/etc/udev/rules.d/83-webcam-removed.rules
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="05a9", ENV{ID_MODEL_ID}=="4519", RUN+="/path/to/your/script"
Lister les attributs d'un périphérique
Pour obtenir une liste de tous les attributs d'un périphérique que vous pouvez utiliser pour écrire des règles, exécutez cette commande :
$ udevadm info --attribute-walk --name=device_name
Remplacez device_name par le périphérique présent dans le système, tel que /dev/sda ou /dev/ttyUSB0.
Si vous ne connaissez pas le nom du périphérique, vous pouvez également lister tous les attributs d'un chemin système spécifique :
$ udevadm info --attribute-walk --path=/sys/class/backlight/acpi_video0
Pour affiner la recherche d'un périphérique, déterminez sa classe et exécutez :
$ ls /dev/class/by-id
Vous pouvez utiliser le lien symbolique ou ce qu'il pointe comme entrée de --name. Par exemple :
$ udevadm info --attribute-walk --name=/dev/input/by-id/usb-foostan_Corne-event-kbd
Pour obtenir le chemin d'un périphérique USB nu qui ne contient aucun périphérique subordonné, vous devez utiliser le chemin complet du périphérique USB. Démarrez le mode moniteur, puis branchez le périphérique USB pour l'obtenir :
$ udevadm monitor
... KERNEL[26652.638931] add /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:05.0/0000:05:00.0/usb1/1-3 (usb) KERNEL[26652.639153] add /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:05.0/0000:05:00.0/usb1/1-3/1-3:1.0 (usb) ...
Vous pouvez simplement choisir le chemin le plus profond et --attribute-walk montrera de toute façon tous les attributs du parent :
Vous pouvez simplement choisir le chemin le plus profond et --attribute-walk montrera de toute façon tous les attributs du parent :
$ udevadm info --attribute-walk --path=/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:05.0/0000:05:00.0/usb1/1-3/1-3:1.0
Test des règles avant le chargement
# udevadm test $(udevadm info --query=path --name=device_name) 2>&1
Cette procédure n'exécutera pas toutes les actions de vos nouvelles règles, mais elle traitera les règles symlink sur les périphériques existants, ce qui peut s'avérer utile si vous ne parvenez pas à les charger autrement. Vous pouvez également fournir directement le chemin du périphérique pour lequel vous voulez tester la règle udev :
# udevadm test /sys/class/backlight/acpi_video0/
Charger de nouvelles règles
udev détecte automatiquement les modifications apportées aux fichiers de règles, ainsi les changements prennent effet immédiatement sans nécessiter le redémarrage de udev. Cependant, les règles ne sont pas redéclenchées automatiquement sur les périphériques déjà existants. Les périphériques connectables à chaud, comme les périphériques USB, devront probablement être reconnectés pour que les nouvelles règles prennent effet, ou au moins décharger et recharger les modules du noyau ohci-hcd et ehci-hcd et ainsi recharger tous les pilotes USB.
Si les règles ne se rechargent pas automatiquement :
# udevadm control --reload
Pour forcer manuellement udev à déclencher vos règles :
# udevadm trigger
udisks
Consultez udisks.
Trucs et astuces
Montage de lecteurs dans les règles
Pour monter des disques amovibles, n'appelez pas mount à partir des règles udev. Ceci est déconseillé pour deux raisons :
- systemd exécute par défaut
systemd-udevd.serviceavec un "espace de noms mount" séparé (consultez namespaces(7)), ce qui signifie que les montages ne seront pas visibles pour le reste du système. - Même si vous changez les paramètres du service pour résoudre ce problème (en commentant les lignes
PrivateMountsetMountFlags), il y a un autre problème qui est que les processus démarrés depuis Udev sont tués après quelques secondes. Dans le cas des systèmes de fichiers FUSE, tels que NTFS-3G, mount démarre un processus en espace utilisateur pour gérer les internes du système de fichiers ; lorsque celui-ci est tué, vous obtiendrez des erreursTransport endpoint not connectedsi vous essayez d'accéder au système de fichiers.
Il existe quelques options qui fonctionnent :
- Démarrer un service systemd personnalisé à partir de la règle Udev ; le service systemd peut invoquer un script qui peut démarrer un nombre quelconque de processus longs (comme FUSE). Un exemple concis qui monte automatiquement les disques USB sous
/mediaest udev-media-automount. Une variante de la même idée est expliquée dans ce post de blog. - Utilisez
systemd-mountau lieu demountdans votre règle Udev. Ceci est recommandé par les développeurs de systemd. Par exemple, cette règle Udev devrait monter les disques USB sous/media:
ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem", RUN{program}+="/usr/bin/systemd-mount --no-block --automount=yes --collect $devnode /media"
- Utilisez un paquet comme udisks ou udiskie. Ils sont très puissants, mais difficiles à mettre en place. De plus, ils sont destinés à être utilisés dans des sessions mono-utilisateur, car ils rendent certains systèmes de fichiers disponibles sous la propriété de l'utilisateur non privilégié dont la session est actuellement active.
Permettre aux utilisateurs normaux d'utiliser les périphériques
Lorsqu'un pilote noyau initialise un périphérique, l'état par défaut du nœud de périphérique est d'être la propriété de root:root, avec les permissions 600. [1] Cela rend les périphériques inaccessibles aux utilisateurs normaux, à moins que le pilote ne modifie la valeur par défaut, ou qu'une règle udev dans l'espace utilisateur ne modifie les permissions.
Les valeurs udev OWNER, GROUP, et MODE peuvent être utilisées pour fournir un accès, bien que l'on rencontre le problème de savoir comment rendre un périphérique utilisable par tous les utilisateurs sans être trop permissif. L'approche d'Ubuntu consiste à créer un groupe plugdev auquel les périphériques sont ajoutés, mais cette pratique est non seulement déconseillée par les développeurs de systemd, [2] mais considérée comme un bogue lorsqu'elle est livrée dans les règles udev sur Arch (FS#35602).
L'approche recommandée est d'utiliser un MODE de 660 pour laisser le groupe utiliser le périphérique, puis d'attacher une TAG nommée uaccess. Cette balise spéciale permet à udev d'appliquer une dynamic user ACL au noeud du périphérique, qui se coordonne avec systemd-logind(8) pour rendre le périphérique utilisable par les utilisateurs connectés. Exemple de règle udev implémentant ceci :
/etc/udev/rules.d/71-device-name.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="vendor_id", ATTRS{idProduct}=="product_id", MODE="0660", TAG+="uaccess"
Exécution lorsque le câble HDMI est branché ou débranché
Créez la règle /etc/udev/rules.d/95-hdmi-plug.rules avec le contenu suivant :
ACTION=="change", SUBSYSTEM=="drm", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/username/.Xauthority", RUN+="/path/to/script.sh"
Exécuter sur le branchement du câble VGA
Créez la règle /etc/udev/rules.d/95-monitor-hotplug.rules avec le contenu suivant pour lancer arandr lors du branchement d'un câble de moniteur VGA :
KERNEL=="card0", SUBSYSTEM=="drm", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/username/.Xauthority", RUN+="/usr/bin/arandr"
Certains gestionnaires d'affichage stockent le .Xauthority en dehors du répertoire personnel de l'utilisateur. Vous devrez mettre à jour ENV{XAUTHORITY} en conséquence. Par exemple, GNOME Display Manager se présente comme suit :
$ printenv XAUTHORITY
/run/user/1000/gdm/Xauthority
Détecter les nouveaux lecteurs eSATA
Si votre lecteur eSATA n'est pas détecté lorsque vous le branchez, vous pouvez essayer plusieurs choses. Vous pouvez redémarrer avec le eSATA branché. Ou vous pouvez essayer :
# echo 0 0 0 > /sys/class/scsi_host/host*/scan
Ou vous pouvez installer scsiaddAUR (à partir de l'AUR) et essayer :
# scsiadd -s
Avec un peu de chance, votre disque est maintenant dans /dev. Si ce n'est pas le cas, vous pouvez essayer les commandes ci-dessus en cours d'exécution :
# udevadm monitor
pour consulter si quelque chose se passe réellement.
Marquer les ports SATA internes comme eSATA
Si vous avez connecté une baie eSATA ou un autre adaptateur eSATA, le système reconnaîtra toujours ce disque comme un lecteur SATA interne. GNOME et KDE vous demanderont en permanence votre mot de passe root. La règle suivante marquera le port SATA spécifié comme un port eSATA externe. Avec cela, un utilisateur normal de GNOME peut connecter ses disques eSATA à ce port comme une clé USB, sans mot de passe root et ainsi de suite.
/etc/udev/rules.d/10-esata.rules
DEVPATH=="/devices/pci0000:00/0000:00:1f.2/host4/*", ENV{UDISKS_SYSTEM}="0"
DEVPATH peut être trouvée après la connexion du lecteur eSATA avec les commandes suivantes (remplacez sdb en conséquence) :
$ udevadm info --query=path /dev/sdb
/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb
$ find /sys/devices/ -name sdb
/sys/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb
Définition de noms de périphériques statiques
Comme udev charge tous les modules de manière asynchrone, ils sont initialisés dans un ordre différent. Cela peut entraîner un changement aléatoire des noms des périphériques. Une règle udev peut être ajoutée pour utiliser des noms de périphériques statiques. Consultez également Nommage persistant des périphériques pour les périphériques de type bloc et Network configuration#Change interface name pour les périphériques réseau.
Périphérique vidéo
Pour configurer la webcam en premier lieu, reportez-vous à Webcam setup.
L'utilisation de plusieurs webcams affectera les périphériques vidéo comme /dev/video* de manière aléatoire au démarrage. La solution recommandée est de créer des liens symboliques en utilisant une règle udev comme dans #Exemple de règle udev :
/etc/udev/rules.d/83-webcam.rules
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", SYMLINK+="video-cam1"
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="08f6", SYMLINK+="video-cam2"
/dev/video* brisera le préchargement de v4l1compat.so et peut-être de v4l2convert.so
Imprimante
Si vous utilisez plusieurs imprimantes, les périphériques /dev/lp[0-9] seront attribués de manière aléatoire au démarrage, ce qui perturbera par exemple la configuration de CUPS.
Vous pouvez créer la règle suivante, qui créera des liens symboliques sous /dev/lp/by-id et /dev/lp/by-path, de manière similaire au schéma du nommage persistant des périphériques :
/etc/udev/rules.d/60-persistent-printer.rules
ACTION=="remove", GOTO="persistent_printer_end"
# Ceci ne devrait pas être nécessaire
#KERNEL!="lp*", GOTO="persistent_printer_end"
SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id"
ENV{ID_TYPE}!="imprimante", GOTO="persistent_printer_end"
ENV{ID_SERIAL}=="?*", SYMLINK+="lp/by-id/$env{ID_BUS}-$env{ID_SERIAL}"
IMPORT{builtin}="path_id"
ENV{ID_PATH}=="?*", SYMLINK+="lp/by-path/$env{ID_PATH}"
LABEL="persistent_printer_end"
Identifier un disque par son numéro de série
Pour effectuer une action sur un périphérique disque spécifique /dev/sdX identifié de manière permanente par son numéro de série unique ID_SERIAL_SHORT tel qu'affiché avec udevadm info /dev/sdX, on peut utiliser la règle suivante. Elle passe comme paramètre le nom du périphérique trouvé s'il y en a un pour illustrer :
/etc/udev/rules.d/69-disk.rules
ACTION=="add", KERNEL=="sd[a-z]", ENV{ID_SERIAL_SHORT}=="X5ER1ALX", RUN+="/path/to/script /dev/%k"
Réveil de la suspension avec un périphérique USB
Une règle udev peut être utile pour activer la fonctionnalité de réveil d'un périphérique USB, comme une souris ou un clavier, afin de pouvoir l'utiliser pour sortir la machine de la veille.
cat /proc/acpi/wakeup. La règle ci-dessous n'est dans ce cas pas nécessaire mais peut être utilisée comme modèle pour effectuer d'autres actions, comme la désactivation de la fonctionnalité de réveil par exemple.
Tout d'abord, identifiez les identifiants du fournisseur et du produit du périphérique USB. Ils seront utilisés pour le reconnaître dans la règle udev. Par exemple :
$ lsusb | grep Logitech
Bus 007 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Ensuite, trouvez l'endroit où le périphérique est connecté en utilisant :
$ grep c52b /sys/bus/usb/devices/*/idProduct
/sys/bus/usb/devices/1-1.1.1.4/idProduct:c52b
Créez maintenant la règle pour modifier l'attribut power/wakeup du périphérique et du contrôleur USB auquel il est connecté à chaque fois qu'il est ajouté :
/etc/udev/rules.d/50-wake-on-device.rules
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", ATTR{power/wakeup}="enabled", ATTR{driver/1-1.1.1.4/power/wakeup}="enabled"
Déclenchement d'événements
Il peut être utile de déclencher divers événements udev. Par exemple, vous pourriez vouloir simuler la déconnexion d'un périphérique USB sur une machine distante. Dans ce cas, utilisez udevadm trigger :
# udevadm trigger --verbose --type=subsystems --action=remove --subsystem-match=usb --attr-match="idVendor=abcd"
Cette commande déclenchera un événement de suppression USB sur tous les périphériques USB avec l'ID du fournisseur abcd.
Démarrer des processus à long terme
Les programmes lancés par udev bloqueront les autres événements provenant de ce périphérique, et toutes les tâches créées à partir d'une règle udev seront tuées une fois le traitement des événements terminé. Si vous devez lancer un processus à long terme avec udev, vous pouvez utiliser at. (par exemple, your_command | at now, ou batch), ou créer une unité systemd qui peut être déclenchée directement depuis une règle udev.
Dépannage
Liste noire de modules
Dans de rares cas, udev peut faire des erreurs et charger les mauvais modules. Pour l'empêcher de le faire, vous pouvez mettre sur liste noire les modules. Une fois mis sur liste noire, udev ne chargera jamais ce module - ni au démarrage, ni plus tard lorsqu'un événement hot-plug est reçu (par exemple, lorsque vous branchez votre clé USB).
Sortie de débogage
Pour obtenir des informations sur le matériel débogage, utilisez le paramètre du noyau udev.log-priority=debug. Vous pouvez également définir
/etc/udev/udev.conf
udev_log="debug"
Cette option peut également être compilée dans votre initramfs en ajoutant le fichier de configuration à votre tableau FILES
/etc/mkinitcpio.conf
FILES="... /etc/udev/udev.conf"
et ensuite régénérez l'initramfs.
udevd se bloque au démarrage
Après la migration vers LDAP ou la mise à jour d'un système basé sur LDAP, udevd peut se bloquer au démarrage avec le message "Starting UDev Daemon". Cela est généralement dû au fait que udevd essaie de rechercher un nom dans LDAP mais échoue, car le réseau n'est pas encore opérationnel. La solution est de s'assurer que tous les noms de groupes du système sont présents localement.
Extrayez les noms de groupes référencés dans les règles de udev et les noms de groupes réellement présents sur le système :
# grep -Fr GROUP /etc/udev/rules.d/ /usr/lib/udev/rules.d/ | sed 's :.*GROUP="\([-a-z_]\{1,\}\)".*:\1:' | sort -u >udev_groups
# cut -d : -f1 /etc/gshadow /etc/group | sort -u >present_groups
Pour consulter les différences, faites une comparaison côte à côte :
# diff -y present_groups udev_groups ... network < nobody < ntp < optique optique puissance < pcscd rfkill < root root scanner scanner smmsp < stockage stockage ...
Dans ce cas, le groupe pcscd est pour une raison quelconque absent du système. Ajouter les groupes manquants. Assurez-vous également que les ressources locales sont recherchées avant de recourir à LDAP. /etc/nsswitch.conf devrait contenir la ligne suivante :
group : files ldap
Certains périphériques, qui devraient être traités comme amovibles, ne le sont pas
Vous devez créer une règle udev personnalisée pour ce périphérique particulier. Pour obtenir des informations définitives sur le périphérique, vous pouvez utiliser soit ID_SERIAL, soit ID_SERIAL_SHORT. (n'oubliez pas de modifier /dev/sdb si nécessaire) :
$ udevadm info /dev/sdb | grep ID_SERIAL
Ensuite, définissez UDISKS_AUTO="1" pour marquer le périphérique pour le montage automatique et UDISKS_SYSTEM="0" pour marquer le périphérique comme "amovible". Consultez udisks(8) pour plus de détails.
/etc/udev/rules.d/99-removable.rules
ENV{ID_SERIAL_SHORT}== "serial_number", ENV{UDISKS_AUTO}="1", ENV{UDISKS_SYSTEM}="0"
N'oubliez pas de recharger les règles udev avec udevadm control --reload. La prochaine fois que vous brancherez votre périphérique, il sera traité comme un disque externe.
Problèmes de son avec certains modules non chargés automatiquement
Certains utilisateurs ont attribué ce problème à d'anciennes entrées dans /etc/modprobe.d/sound.conf. Essayez de nettoyer ce fichier et réessayez.
udev>=171, les modules d'émulation OSS (snd_seq_oss, snd_pcm_oss, snd_mixer_oss) ne sont pas chargés automatiquement par défaut.Prise en charge des lecteurs de CD/DVD IDE
À partir de la version 170, udev ne prend pas en charge les lecteurs de CD-ROM/DVD-ROM qui sont chargés comme des lecteurs IDE traditionnels avec le module ide_cd_mod et qui apparaissent sous la forme /dev/hd*. Le lecteur reste utilisable pour les outils qui accèdent directement au matériel, comme cdparanoia, mais est invisible pour les programmes supérieurs en espace utilisateur, comme KDE.
Une cause pour le chargement du module ide_cd_mod avant les autres, comme sr_mod, pourrait être par exemple que vous avez pour une raison quelconque le module piix chargé avec votre initramfs. Dans ce cas, vous pouvez simplement le remplacer par ata_piix dans votre /etc/mkinitcpio.conf.
Les lecteurs optiques ont un ID de groupe défini sur "disk"
Si l'ID de groupe de votre lecteur optique est défini sur disk et que vous souhaitez qu'il soit défini sur optical, vous devez créer une règle udev personnalisée :
/etc/udev/rules.d
# Permissions pour les périphériques CD IDE
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"
# permissions pour les périphériques CD SCSI
SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"
Les programmes graphiques dans les règles RUN se bloquent lorsqu'aucun serveur X n'est présent
Lorsque xrandr ou un autre programme basé sur X tente de se connecter à un serveur X, il se rabat sur une connexion TCP en cas d'échec. Cependant, à cause de IPAddressDeny dans la systemd-udev service configuration, cela se bloque. Finalement, le programme sera tué et le traitement des événements reprendra.
Si la règle est destinée à un périphérique drm et que le blocage entraîne la fin du traitement des événements après le démarrage du serveur X, l'accélération 3D peut cesser de fonctionner avec une erreur failed to authenticate magic.