Le ThinkCentre M710q ne possède aucune option BIOS pour désactiver les LEDs, contrairement aux modèles haut de gamme. Les solutions logicielles Linux sont limitées pour les LEDs matérielles (alimentation, activité disque), mais fonctionnent partiellement pour les LEDs réseau. La méthode la plus fiable combine des scripts de persistance Proxmox avec des modifications physiques simples et réversibles comme du ruban adhésif opaque. Cette approche multi-couches garantit l'extinction permanente de toutes les sources lumineuses.

Réalité technique du M710q et limitations BIOS

La recherche exhaustive dans la documentation officielle Lenovo, les manuels de maintenance et les forums techniques confirme une vérité dérangeante : le M710q (chipset B250) ne propose aucun paramètre BIOS/UEFI pour contrôler les LEDs. Cette limitation s'étend à toute la série ThinkCentre Tiny de cette génération (M710q, M720q, M920q sans vPro). Les menus BIOS incluent la gestion d'alimentation, les périphériques intégrés et la sécurité, mais aucune section pour les LEDs. Même les communautés de modding BIOS (Win-Raid, Badcaps) ne rapportent aucune option cachée débloquable.

Cette absence de contrôle BIOS signifie que les LEDs sont câblées directement à la carte mère sans abstraction firmware. Les LEDs présentes sur le M710q incluent la LED d'alimentation blanche/ambre en façade (la plus problématique car elle "respire" en veille), la LED d'activité disque, et les LEDs réseau orange/vert sur le port RJ45. Lenovo considère ces indicateurs comme essentiels pour le diagnostic matériel et n'a pas priorisé leur désactivation dans ce segment de marché professionnel.

Solutions logicielles pour Proxmox : configuration permanente

Bien que les LEDs d'alimentation et d'activité disque soient rarement contrôlables via logiciel sur les PC de bureau, certaines LEDs peuvent être gérées via /sys/class/leds/ et les LEDs réseau via ethtool. Voici une approche complète pour Proxmox.

Première étape : identifier les LEDs disponibles. Exécutez ls /sys/class/leds/ pour lister les LEDs contrôlables via sysfs. Sur le M710q, ce répertoire est souvent vide ou contient uniquement des LEDs de périphériques internes non visibles. Vérifiez également avec find /sys -name '*led*' -type d pour localiser d'autres chemins LED potentiels.

Deuxième étape : créer un script de désactivation universel. Créez /usr/local/bin/disable-all-leds.sh avec le contenu suivant :

#!/bin/bash
# Désactive toutes les LEDs système via sysfs
for led in /sys/class/leds/*/brightness; do
    [ -e "$led" ] && echo 0 > "$led" 2>/dev/null || true
done

for trigger in /sys/class/leds/*/trigger; do
    [ -e "$trigger" ] && echo none > "$trigger" 2>/dev/null || true
done

# Désactive Wake-on-LAN qui peut maintenir LEDs actives
for iface in $(ls /sys/class/net/ | grep -E '^(eth|eno|enp)'); do
    if [ -e "/sys/class/net/$iface/device" ]; then
        ethtool -s "$iface" wol d 2>/dev/null || true
    fi
done

logger -t disable-leds "Script exécuté avec succès"
exit 0

Rendez-le exécutable : chmod +x /usr/local/bin/disable-all-leds.sh

Troisième étape : persistance via systemd. Créez /etc/systemd/system/disable-leds.service :

[Unit]
Description=Désactivation permanente des LEDs matérielles
After=network.target multi-user.target
Before=pve-cluster.service pve-guests.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/disable-all-leds.sh
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Activez le service :

systemctl daemon-reload
systemctl enable disable-leds.service
systemctl start disable-leds.service
systemctl status disable-leds.service

Quatrième étape : couche de sauvegarde avec tmpfiles.d. Créez /etc/tmpfiles.d/disable-leds.conf pour une application au démarrage :

w /sys/class/leds/PWR/brightness - - - - 0
w /sys/class/leds/ACT/brightness - - - - 0
w /sys/class/leds/led0/brightness - - - - 0
w /sys/class/leds/PWR/trigger - - - - none
w /sys/class/leds/ACT/trigger - - - - none

Appliquez immédiatement : systemd-tmpfiles --create /etc/tmpfiles.d/disable-leds.conf

Cette approche multi-couches (systemd + tmpfiles.d) maximise les chances de désactivation même si certains chemins LED changent ou n'existent pas.

LEDs réseau : méthodes spécifiques au M710q

Le M710q utilise généralement une carte réseau Intel I219-V/LM (pilote e1000e). Les LEDs réseau orange (activité) et vert (lien) sont les plus visibles et gênantes pour le sommeil.

Méthode 1 : désactivation du Wake-on-LAN. Cette commande est déjà incluse dans le script ci-dessus, mais peut être exécutée manuellement : ethtool -s eth0 wol d (remplacez eth0 par votre interface réseau, vérifiez avec ip link). Cette commande désactive le WOL qui peut maintenir les LEDs actives même après extinction.

Méthode 2 : modification NVM Intel (solution permanente au niveau matériel). Pour une désactivation définitive des LEDs réseau sur les cartes Intel, vous pouvez modifier la mémoire non-volatile de la carte. Cette méthode nécessite des précautions mais offre une solution permanente même après réinstallation complète du système.

Identifiez votre carte Intel : lspci -nnq | grep Ethernet Exemple de sortie : Ethernet controller [0200]: Intel Corporation [8086:1559]

Lisez la configuration LED actuelle : sudo ethtool -e eth0 offset 0x30 length 2

Calculez la clé magique (vendor | (device << 16)). Pour 8086:1559, c'est 0x15598086.

Écrivez la configuration LED désactivée :

sudo ethtool -E eth0 magic 0x15598086 offset 0x30 value 0xa5
sudo ethtool -E eth0 magic 0x15598086 offset 0x31 value 0x14

Attention importante : la modification NVM nécessite un pilote e1000e récent qui supporte l'écriture EEPROM. Le pilote par défaut de Proxmox peut ne pas supporter cette fonctionnalité. Une erreur courante est "NVM write not supported". Dans ce cas, téléchargez et compilez le pilote Intel le plus récent depuis le site Intel. Après modification NVM, rechargez le pilote (modprobe -r e1000e && modprobe e1000e) ou redémarrez. Cette modification persiste même après changements d'OS.

Méthode 3 : règles udev pour interfaces réseau. Créez /etc/udev/rules.d/80-disable-network-leds.rules :

ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*", RUN+="/usr/local/bin/disable-all-leds.sh"

Rechargez les règles : sudo udevadm control --reload-rules && sudo udevadm trigger

Vérification et dépannage de la persistance

Après configuration, vérifiez l'état des LEDs avec ces commandes :

# Vérifier les LEDs disponibles
ls -la /sys/class/leds/

# Vérifier l'état des LEDs (brightness devrait être 0)
grep -r . /sys/class/leds/*/brightness 2>/dev/null

# Vérifier les triggers (devrait afficher [none])
grep -r . /sys/class/leds/*/trigger 2>/dev/null

# Vérifier que le service systemd s'est exécuté
systemctl status disable-leds.service

# Consulter les logs du service
journalctl -u disable-leds.service -b

Si le répertoire /sys/class/leds/ est vide ou inexistant, c'est normal pour le M710q - cela confirme que les LEDs d'alimentation et d'activité ne sont pas accessibles via logiciel. Dans ce cas, les solutions physiques deviennent obligatoires.

Pour tester le script manuellement et voir les erreurs potentielles : bash -x /usr/local/bin/disable-all-leds.sh

Si le service systemd ne démarre pas, vérifiez les permissions du script (ls -la /usr/local/bin/disable-all-leds.sh) et assurez-vous qu'il est exécutable. Consultez les journaux détaillés avec journalctl -xe -u disable-leds.service.

Solutions physiques : méthodes réversibles et efficaces

Puisque le M710q ne permet pas de contrôler logiciellement les LEDs principales (alimentation et activité disque), les méthodes physiques sont incontournables pour une solution complète. La bonne nouvelle est que ces méthodes sont simples, réversibles et n'affectent pas la garantie si elles sont appliquées correctement.

Méthode recommandée : autocollants de blocage LED. Disponibles sur Amazon sous le nom "LED dimming dots" ou "light blocking tape", ces autocollants pré-découpés sont spécifiquement conçus pour bloquer la lumière LED. Recherchez des produits avec opacité 100% et appliquez-les directement sur la LED du bouton d'alimentation et la LED d'activité disque. Ces autocollants offrent une finition propre, sont facilement amovibles et coûtent quelques euros. Les utilisateurs homelab les recommandent massivement pour les serveurs domestiques.

Alternative économique : ruban adhésif électrique noir. Le ruban isolant électrique noir standard (3M ou similaire) fonctionne bien mais nécessite 2-3 couches superposées pour les LEDs très lumineuses. Nettoyez d'abord la surface avec de l'alcool isopropylique, découpez un petit morceau de ruban et appliquez-le fermement en éliminant les bulles d'air. L'inconvénient esthétique est compensé par la disponibilité immédiate et le coût négligeable. Évitez le ruban adhésif transparent ou le vernis à ongles seul, trop transparents pour les LEDs blanches/bleues du M710q.

Modification interne avancée : application de ruban sur les composants LED. Pour une solution plus propre esthétiquement, ouvrez le boîtier du M710q (une seule vis à l'arrière, conception tool-less) et appliquez du ruban adhésif noir directement sur les composants LED situés sur la petite carte PCB du panneau avant. Cette méthode évite l'aspect "bricolé" visible de l'extérieur et reste totalement réversible. Attention critique : avant d'ouvrir le boîtier, débranchez complètement l'alimentation et attendez 30 secondes. Portez un bracelet antistatique si possible. Ne confondez pas les connecteurs LED avec le connecteur du bouton d'alimentation - débrancher le mauvais connecteur vous empêcherait d'allumer l'ordinateur.

Déconnexion des LEDs (méthode experte). Si vous êtes à l'aise avec l'électronique, localisez le connecteur de panneau avant (généralement étiqueté "F_PANEL") sur la carte mère. Les pins LED sont typiquement PLED+ et PLED- pour la LED d'alimentation, HDD_LED+ et HDD_LED- pour l'activité disque. Ne déconnectez QUE les pins LED, jamais les pins PWRSW (bouton d'alimentation) ou RST (reset). Sur certains modèles Tiny, il s'agit d'un connecteur multi-pins unique - dans ce cas, la déconnexion complète n'est pas recommandée. La méthode du ruban reste plus sûre.

Stratégie globale recommandée : approche combinée

Pour obtenir une extinction complète et permanente de toutes les sources lumineuses du M710q sous Proxmox, appliquez cette stratégie multi-niveaux :

Niveau 1 : Configuration logicielle Proxmox. Implémentez le service systemd et tmpfiles.d décrits ci-dessus. Même si /sys/class/leds/ est vide, le script désactive le Wake-on-LAN qui peut influencer les LEDs réseau. Cette configuration prend 10 minutes et persiste après redémarrages et mises à jour Proxmox. Testez le service avec systemctl start disable-leds.service puis vérifiez les logs.

Niveau 2 : LEDs réseau. Si les LEDs du port Ethernet restent actives et gênantes, commencez par désactiver WOL (déjà dans le script). Si insuffisant, envisagez la modification NVM Intel pour une solution permanente au niveau firmware. Cette modification survit aux changements d'OS et ne nécessite qu'une seule intervention. Alternativement, positionnez simplement le M710q de sorte que l'arrière (avec le port Ethernet) soit orienté loin de votre zone de sommeil.

Niveau 3 : LEDs matérielles (alimentation et activité). Appliquez des autocollants de blocage LED ou du ruban électrique noir sur la LED du bouton d'alimentation (la plus problématique, surtout en mode veille avec son effet "respirant") et la LED d'activité disque. Prévoyez 2-3 couches pour un blocage complet de lumière. Cette étape prend 5 minutes et est entièrement réversible. C'est la solution utilisée par 95%+ de la communauté homelab pour ce problème.

Niveau 4 : Gestion d'alimentation alternative. Si la LED de veille "respirante" reste problématique malgré le ruban, modifiez la gestion d'alimentation Proxmox pour utiliser l'hibernation ou l'extinction complète au lieu de la mise en veille. Dans Proxmox, l'hibernation (systemctl hibernate) ou l'extinction éteint complètement toutes les LEDs. Le compromis est un temps de réveil plus long (30-60 secondes vs 2-3 secondes), mais pour un serveur domestique, c'est souvent acceptable.

Temps total d'implémentation : 20-30 minutes pour la solution complète. Coût : 0-10€ (autocollants LED). Résultat : obscurité totale, solution permanente, entièrement réversible sauf si modification NVM appliquée.

Conclusion : aucune solution miracle, mais combinaison efficace

Le ThinkCentre M710q illustre une décision de conception Lenovo : les LEDs de diagnostic sont câblées au niveau matériel sans abstraction logicielle, reflétant la philosophie "business desktop" où les indicateurs visuels sont considérés essentiels. L'absence de contrôle BIOS et l'exposition limitée via sysfs signifient qu'une solution purement logicielle n'existe pas pour ce modèle. Les communautés techniques (ServeTheHome, Proxmox forums, r/homelab) confirment unanimement que les modifications physiques sont inévitables pour les LEDs principales.

La stratégie recommandée combine scripts de persistance Proxmox (pour LEDs réseau et cas où de futures mises à jour firmware exposeraient de nouveaux contrôles) avec application simple de ruban opaque sur les LEDs matérielles. Cette approche pragmatique est testée par des milliers d'utilisateurs homelab et offre le meilleur rapport efficacité/temps/réversibilité. Pour les utilisateurs privilégiant l'esthétique, l'ouverture du boîtier pour application interne de ruban offre un résultat professionnel en 15 minutes supplémentaires.

L'ironie finale : les modèles ThinkCentre plus anciens avaient parfois des LEDs moins lumineuses, tandis que les modèles récents (M70q, M80q Gen 3+) utilisent des LEDs encore plus brillantes. Lenovo n'a pas ajouté de contrôle LED dans les générations suivantes, suggérant que cette fonctionnalité ne sera pas priorisée. Pour les futurs achats, vérifiez les spécifications LED ou considérez les modèles HP EliteDesk ou Dell OptiPlex qui offrent occasionnellement plus d'options BIOS, bien que sans garantie.

L'objectif d'obscurité complète est atteignable avec les méthodes décrites. Testez d'abord l'approche la moins invasive (ruban externe) et progressez vers les modifications internes uniquement si nécessaire. Documentez vos modifications si le système est sous garantie, bien que l'application de ruban n'affecte généralement pas la couverture. Bonne nuit sans LEDs agaçantes.