Cédrix
1 line
12 KiB
JSON
1 line
12 KiB
JSON
[{"uuid":"e281be87-2150-4d57-930b-61ac703345d9","slug":"50-20210114-jeudi-geek","title":"Jeudi Geek : signal, boot loader, linux et interface en chinois","category":"Podcasts","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2021-01-14 01:37:02","created_at":"2021-01-14 01:37:02","updated_at":"2021-01-14 01:37:02","tags":[],"plain":"Voici le 50ème épisode : Jeudi Geek : signal, boot loader, linux et interface en chinois\nCette page est amenée à évoluer. Réagissez à cet épisode dans la partie [Épisode disponible sur https://info.mindcast.fr/]\n--"},{"uuid":"6ec15a01-2b27-4064-90e4-23468374295e","slug":"reboot","title":"reboot","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-18 08:54:40","created_at":"2023-02-18 08:54:40","updated_at":"2023-02-18 08:54:40","tags":[],"plain":"C'est un programme présent dans . Par conséquent il doit être appelé avec les droits . Il permet de redémarrer l'ordinateur. Le programme fait partie du groupe , , et , tous ayant un lien symbolique avec quand le système est piloté avec SystemD. Par bonne habitude, il vaut mieux utiliser la commande : Vous pouvez aussi appuyer sur la combinaison de touches Ctrl+Alt+Del."},{"uuid":"8da6da4b-5b28-4f67-b6f7-277ee42843ce","slug":"de-zigbee2mqtt-a-proxmox-l-effet-papillon-d-un-switch-defaillant","title":"De Zigbee2MQTT à Proxmox : l’effet papillon d’un switch défaillant","category":"domotique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-05-25 06:01:36","created_at":"2025-05-25 06:01:36","updated_at":"2025-05-25 06:01:36","tags":{"logiciels":["Home Assistant"]},"plain":"Contexte initial\r\n\r\nDepuis plusieurs semaines, je soupçonnais mon coordinateur Zigbee SLZB-06M (Ethernet + PoE) de provoquer des instabilités réseau sous Zigbee2MQTT. Les symptômes étaient clairs : redémarrages en boucle du service, erreurs , commandes Zigbee échouées… Bref, une stack Zigbee instable malgré une configuration soignée.\r\n\r\nJ’avais tout envisagé : firmware Ember instable, problème d’alimentation PoE, bugs dans le bridge UART-to-TCP, saturation du port TCP 6638. J’ai même reflashé le dongle et validé la configuration YAML ligne par ligne. Sans succès. Toujours les mêmes erreurs :\r\n\r\n\r\n\r\nJ’envisageais déjà de tout remplacer : passer à un dongle USB, revoir le routage, refaire un mesh propre. Et puis...\r\n--\r\n\r\nL’incident du lundi matin\r\n\r\nUn blackout complet frappe mon infra : plus aucun service local ou distant ne répond. Proxmox, Zigbee2MQTT, partages NFS, Home Assistant, NAS — tout semble mort. Même l’accès Internet est intact, mais tout ce qui repose sur mon réseau interne est figé.\r\n\r\nJ’isole alors le NAS (la machine hôte centrale qui héberge tout le stockage via Proxmox), le connecte localement via un boîtier d’acquisition HDMI. Rien. Écran noir.\r\n\r\nJe commence à douter de tout : le câble DisplayPort ? Le boîtier HDMI ? Le BIOS ? Je teste, redémarre, écoute. Trois bips longs. Rien à l’écran. Jusqu’à ce que je réalise que j’attendais une image 1080p… alors que le BIOS sort du 640x480. Je reconfigure OBS (oui, parce que je passe par OBS pour afficher mes périphériques), ajuste la fréquence… et là, miracle :\r\n« Press to enter Setup or to enter Boot Menu »\r\n\r\nS’ensuivent des erreurs BIOS typiques :\r\n--\r\n\r\nLe coupable n°1 : la pile CMOS\r\n\r\nLa pile bouton est morte. Résultat : perte des paramètres BIOS à chaque redémarrage, y compris le boot sur disque. Je la remplace par une neuve (CR2032 à 3,1V), et tout rentre dans l’ordre… en apparence.\r\n\r\nJe replace le serveur. Et là, à nouveau : plus rien. Ping muet. Services inaccessibles. Home Assistant muet. Zigbee2MQTT en erreur.\r\n--\r\n\r\nLe vrai coupable : le switch réseau\r\n\r\nUn doute m’envahit. Je regarde le switch PoE. Il est éteint. Plus une LED.\r\n\r\nJe le remplace immédiatement. Nouveau switch, même câblage. Et tout revient :\r\n\r\n Proxmox opérationnel\r\n Partages NFS montés\r\n Home Assistant réactif\r\n Zigbee2MQTT sans erreur\r\n--\r\n\r\nLe lien entre les deux incidents\r\n\r\nC’est là que tout devient limpide.\r\n\r\n Le switch défaillant provoquait des microcoupures entre les VMs et le stockage.\r\n Les erreurs ECONNRESET de Zigbee2MQTT venaient du lien instable entre le coordinateur Ethernet et le service.\r\n L’instabilité du réseau expliquait les redémarrages en boucle, les commandes Zigbee échouées, les automatisations manquantes.\r\n\r\nEt pendant ce temps, je blâmais le coordinateur Zigbee, le firmware Ember ou un bug MQTT… alors que tout venait d’un simple transformateur à 10€ du switch.\r\n--\r\n\r\nBilan\r\n\r\nCe que j’ai appris :\r\n\r\n Ne jamais sous-estimer un composant “passif” : un switch, une pile, une alimentation.\r\n Un bug réseau peut se déguiser en bug applicatif.\r\n Les microcoupures sont pires que les pannes franches : elles érodent les services sans les faire crasher complètement, rendant le diagnostic flou.\r\n Observer avant d’agir, c’est vital. Sinon, on démonte tout… pour rien.\r\n--\r\n\r\nEt maintenant ?\r\n\r\nTout est reparti. Le coordinateur Zigbee SLZB-06M fonctionne parfaitement. Plus aucun redémarrage du service. Plus d’. Les automatisations sont de retour.\r\n\r\nParfois, c’est \"juste\" un switch qu'il faut changer !**"},{"uuid":"55a2c5eb-74d2-4c58-a7d1-19d1d824adf1","slug":"incident-acegrp-lan-2-tout-s-explique-enfin","title":"Incident acegrp.lan (2) : Tout s’explique enfin !","category":"domotique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-04-30 18:01:00","created_at":"2025-04-30 18:01:00","updated_at":"2025-05-01 04:30:09","tags":[],"plain":"Nous sommes lundi matin. Le silence numérique est assourdissant. Aucun service interne ne répond, et les plateformes A5L sur Internet sont totalement inaccessibles. Rien ne fonctionne. C’est un black-out complet. Le genre de panne qui érode patiemment ton calme et ton raisonnement, heure après heure. La veille, j’avais déjà tout tenté ou presque, sans succès. Et maintenant, le temps presse. Je décide de rapatrier la machine hôte qui fait tourner le NAS, la pièce centrale du puzzle. Ce mini-serveur, habituellement discret et stable, est suspect numéro un. Peut-être qu’en le branchant localement, j’aurai enfin un retour vidéo. Je tente une nouvelle approche : je le connecte à un boîtier d’acquisition HDMI, en utilisant simplement un câble DisplayPort vers HDMI. L’idée est de faire apparaître quelque chose, n’importe quoi, dans OBS, sur mon poste de travail. Mais tout ce que j’obtiens, c’est un écran noir. Rien. Pas un pixel.\r\n\r\nÀ cet instant, tout devient flou. Je commence à remettre en question chaque élément de la chaîne. Le boîtier d’acquisition : fonctionne-t-il réellement ? Le câble : est-il compatible ? Le port DisplayPort : est-il actif au démarrage ? Et la machine elle-même ? Est-ce qu’elle boote seulement ? Je doute de tout. Ce sont les moments les plus pénibles. Quand la panne est silencieuse. Quand tout semble à la fois en cause, et que rien ne parle. C’est dans ces phases de doute profond que je suis le plus vulnérable. J’ai souvent réagi à l’instinct dans ces moments-là, en allant droit vers des actions irréversibles. Formater un disque, réinstaller un système, démonter un châssis complet… sans prendre le temps d’analyser, de poser les bonnes questions. Je le sais, je l’ai déjà vécu, mais aujourd’hui, j’essaie de faire mieux. Je prends une pause. J’observe. J’écoute.\r\n\r\nJe redémarre plusieurs fois la machine, et à chaque fois, j’entends trois bips, espacés, lents, presque inquiétants. Le disque dur semble tournoyer, sans conviction. Pas de réelle activité. L’écran reste noir. Et c’est là que je me souviens d’un paramètre que je n’ai pas vérifié : la configuration de sortie dans OBS. J’ouvre les paramètres d’entrée vidéo, et je me rends compte que la résolution, la fréquence, tout est réglé comme si j’attendais le signal d’une console de jeu en 1080p. Mais un BIOS ? Il sort en 640x480, peut-être 800x600 dans le meilleur des cas… Je change les réglages, ajuste la fréquence, et je relance.\r\n\r\nEt là, comme un miracle numérique, l’image apparaît. Épurée. Grise. En anglais. \r\n« Press <F2> to enter Setup or <F12> to enter Boot Menu. » \r\nEt puis s’enchaînent les erreurs : \r\nERROR - POST - Invalid date / time \r\nERROR - POST - Bad RTC Battery \r\nBIOS Settings defaults loaded. \r\nLa sentence est claire : la pile CMOS est à plat. Elle ne tient plus la date, plus les réglages, plus rien. C’est elle qui empêchait la machine de démarrer correctement, de retrouver ses marques. Quelle absurdité ! Une simple pile bouton de quelques grammes, dans un PC allumé 24h/24 depuis des années. Mais elle a rendu l’âme, discrètement, en silence, et tout s’est effondré autour.\r\n\r\nJe coupe l’alimentation, j’ouvre le boîtier, je localise la pile. Je la retire et la teste au multimètre : 2,5 volts. C’est insuffisant. Je la remplace immédiatement par une neuve, une bonne CR2032 à 3,1 volts. Je remonte le tout, referme le boîtier, rebranche les câbles, et relance. Et là, la magie opère : l’écran Proxmox s’affiche, le système boote, et — enfin — la machine répond au ping. C’est le genre de petit miracle qui donne envie de se lever et d’applaudir dans une pièce vide.\r\n\r\nJe replace donc le serveur à son emplacement habituel, je le redémarre avec confiance… et là, plus rien. Ping muet. Silence réseau. J’étrangle un soupir. Et si c’était… autre chose ? Mon regard se pose sur le switch réseau. Éteint. Plus une LED. Je débranche, rebranche, rien. Je prends un switch de rechange, je le connecte à la place du défaillant, je relie chaque câble avec soin. Et là, tous les services reviennent. Ping OK. Partages NFS OK. Proxmox OK. Le réseau reprend vie comme si de rien n’était.\r\n\r\nL’autopsie du switch est formelle : alimentation HS. Ce petit boîtier discret avait probablement commencé à agoniser lentement depuis plusieurs jours, provoquant des microcoupures entre le NAS et le serveur principal. Les VM avaient perdu l’accès à leur stockage. Les partages s’étaient effondrés. Et tout ça avait été pris pour un bug de Proxmox, un problème de VM… alors que tout partait d’une alimentation à 10 euros.\r\n\r\nAu final, tout s’explique. La pile. Le switch. Le lien entre les deux. \r\nEt moi, au milieu, à jongler entre câbles, BIOS, doutes et bips. \r\nUne tempête technique partie d’un simple maillon faible."},{"uuid":"cd0a1ad7-7559-40e0-96b3-0bfbf4734d18","slug":"forum-alpinux","title":"Forum Alpinux","category":"linux","author":"cedric@abonnel.fr","cover":"cover.png","published":true,"published_at":"2025-04-04 07:45","created_at":"2025-04-04 07:45:00","updated_at":"2026-05-12 09:42:07","tags":[],"plain":"Hier soir se tenait le Repair du Libre et le Forum Alpinux à Chambéry.\r\n\r\nLors du Repair du Libre, une personne est venue pour faire diagnostiquer son ordinateur. Trois points ont été vérifiés : la batterie, le disque dur et l’espace de stockage. La batterie, âgée de plus de 4 ans, était hors service. En revanche, le disque dur était en bon état selon SmartControl, et l’espace disque disponible était suffisant.\r\n\r\nNous avons également tenté d’installer Linux Mint 22.1 sur un PC sans UEFI, mais l’opération s’est révélée complexe. L’installateur Ubiquity prépare le disque en mode GPT, ce qui n’est pas compatible avec une machine équipée d’un BIOS classique, entraînant l’échec de l’installation.\r\n\r\nPar ailleurs, un autre ordinateur présentait un problème de connexion Wi-Fi : le pilote ne se chargeait pas à cause de Secure Boot. Une fois ce dernier désactivé, la connexion devrait fonctionner normalement.\r\n\r\nEnfin, avec l’aide de Brice, nous avons échangé autour d’OpenStreetMap, StreetComplete et OSMAND pendant le Forum Alpinux. Une contribution collective via StreetComplete est prévue en juin par Alpinux à Chambéry."}] |