Raspberry-Pi OS sur disque dur SSD qui plante sans prévenir!

Bonjour à tous,

Un retour d'expérience chaotique sur les Raspberry-Pi utilisant un SSD comme support principal.

Si votre configuration HDD / SSD cesse de fonctionner sans prévenir, vous trouverez une solution ici !

Centre IoT sur Rasberry-Pi

Il y a peu, j'ai décidé d'installer un centre IoT sur Raspberry-Pi (MQTT, NodeRed, InfluxDB, Grafana) en utilisant The Script de Peter Scargill en reprenant la vidéo de "How Can You Build Your Professionnal Looking Home Server" d'Andreas Spiess.

Le matériel

Pour offrir un peu de punch et pérennisé la configuration, j'ai opté pour:

• Raspberry-Pi 4 4Go + Alimentation officielle
• Ventilla-Pi (ventilateur silencieux)
• Convertisseur USB-Sata d'Olimex + câbles
• Disque SSD 60Go - Kingston SSD Now
  

Configuration simple et efficace.

Installation

Raspberry-Pi Imager a permis de flasher le SSD avec Raspberry-Pi OS Light (je ne comptes pas utiliser l'environnement Desktop mais les environnements WEBs).

Installation et démarrage sans surprise, activation de SSH et exécution du Script pour installer Mosquitto MQTT, Node-Red (entièrement recompilé), InfluxDB, Grafana.

Un petit tour des softs après installation confirme que tout est correctement configuré :-)

Un petit objet IoT

C'est le moment où je me décide à faire un petit objet IoT autour d'un Feather ESP32 sous MicroPython et d'un BME280 (pression atmosphérique, température, humidité) sur base des informations du livre "Python Raspberry Pi et Flash" (Ed. ENI).

Objet placé dans la cabane de jardin et qui ressemble à ceci... 

Objet basé sur le livre "Python Raspberry Pi et Flash"

Et comme suggéré dans l'ouvrage, je surveille l'arrivée des messages sur le broker MQTT depuis mon PC à l'aide de l'utilitaire mosquitto_sub .

$ mosquitto_sub -h 192.168.1.xxx -t "#" -u admin -P xxxxx -v -I pc_dom2

Et c'est là que les ennuis commencent!

Symptômes

Après un délai aléatoire de l'ordre de 15 à 20H, j'ai l'impression que me broker MQTT n'envois plus les messages correspondant à ma souscription. 

Évidemment, c'est l'ESP32 que j'ai mis en cause, il ne semble même pas s'apercevoir qu'il y a un problème (comme si la connexion MQTT n'était pas rompue).

Mais le redémarrage de l'ESP32 n'apporte rien!
Rentré dans la maison (plutôt que dans la cabane de jardin) et un redémarrage ESP32 + Raspberry-Pi et tout rentre dans l'ordre... pendant environ un dizaine d'heures.

Impossible d'établir une nouvelle session MQTT, se connecter sur Grafana, établir une session SSH (le login passe puis plus rien). La LED d'accès SSD ne s'allume plus du tout sur l'interface USB-Sata.

C'est comme si il n'y avait plus de ressources disponibles sur le Pi 4.
Avec 4 Go de RAM et un SSD de 60Go j'ai des doutes.

C'est lors d'un nouveau "plantage" avec une session SSH active, que j'ai remarqué que celle-ci restait active et réactive. Log2Ram étant installé, j'ai put consulter les LOGs où il y a des problèmes d'accès aux ressources.

A l'évidence, il est impossible d'accéder au système de fichier sur le disque SSD, impossible d'ouvrir une nouvelle session SSH, impossible d'établir une nouvelle connexion MQTT!

C'est le disque ou l'interface USB-SATA.
Dans les deux cas, c'est du matériel de qualité (le disque a même été entièrement reformaté).

UAS ou Quirks mode : il faut choisir

UAS est l'acronyme de "Usb Attached Scsi", c'est le mode par défaut utilisé par Raspberry-Pi pour exploiter les disques USB.

Par contre, tous les fabricants de puces USB-Sata ne suivent pas scrupuleusement le protocole (en omettant certaines commandes).

Alors tout va bien pour les cas généraux... puis avec le temps l'OS émet une commande moins courante et...

Tout part en couille! Soit le convertisseur USB-Sata plante, soit le pilote UAS de l'OS plante (suite à un retour d'erreur), voire les deux en même temps.

Dans tous les cas, le périphérique Disque USB devient instable et devient probablement inaccessible.

Solution

Utiliser le quikrs mode (plutôt que UAS) avec le disque USB / USB-Sata.
Et je peux confirmer que cela fonctionne maintenant parfaitement depuis une semaine.

J'ai découvert cette astuce sur le forum de la fondation Raspberry.

• STICKY: If you have a Raspberry Pi 4 and are getting bad speeds transferring data to/from USB3.0 SSDs, read this
  

J'ai listé mes périphériques USB avec la commande lsusb pour repérer le vid:pid du lecteur USB / pilote USB-Sata.

Ensuite, j'ai ajouté l'instruction usb-storage.quirks=0123:4567:u,2109:0715:u en début de ligne du /boot/cmdline.txt

Dans mon cas, lsusb retourne:

 $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp. JM20329 SATA Bridge
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ce qui permet d'identifier le pid:vid de mon interface USB-Sata ( 152d:2329 ).

Le contenu de mon fichier /boot/cmdline.txt ressemble à ceci:

$ cat /boot/cmdline.txt 
usb-storage.quirks=152d:2329u console=serial0,115200 console=tty1 root=PARTUUID=08956c65-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Reste plus qu'a redémarrer le Pi et c'est plié!

Ressources

• The Script de Peter Scargill
  Installation semi-automatisée d'une environnement IoT sur Pi.
  
• How Can You Build Your Professionnal Looking Home Server
  Vidéo YouTube d'Andreas Spiess
• Feather ESP32 d'Adafruit Industries @ MCHobby
• BME280 d'Adafruit Industries @ MCHobby
  Capteur de pression atmosphérique, température, humidité
• Livre Python Raspberry-Pi et Flask aux éditions ENI