Cerebro Seco

Des bugs, vraiment? Plutôt de petits détails fréquemment passés sous silence, ou tenus pour acquis.

Carte SD non bootable, comment s'en prémunir.

Peu de choses sont aussi agaçantes que de passer une vingtaine de minutes à écrire une image système sur une carte SD pour se rendre compte qu'elle est incapable de faire démarrer le Raspberry Pi.

Par exemple:

$ sudo dd if=~/Downloads/2014-06-20-wheezy-raspbian.img of=/dev/disk2 bs=4m
706+1 records in
706+1 records out
2962227200 bytes transferred in 19629.801197 secs (150905 bytes/sec)

Ici, cette image a mis plus de 5 heures et demi à être écrite, ce qui est clairement anormal. En soi, ce n'est pas très parlant, dd lui-même n'a pas la capacité de dire si ce qu'il écrit est valide ou non. On s'en remettra ici aux conseils classiques liés aux téléchargements de fichiers lourds par BitTorrent, particulièrement dans le monde Linux. Avez-vous remarqué que toujours, soit sur la page des téléchargements, soit dans l'archive téléchargé, soit sur la page se trouve un fichier nommé checkcrc, md5sum, sha1sum, ou une longue chaîne de chiffres et lettres apparemment sans signification? Cette chaîne représente le hash du fichier, ou checksum, littéralement "somme de vérification", servant à vérifier si le fichier obtenu est bien celui que l'éditeur a prévu. Pourtant, le téléchargement par torrent est censé faire une vérification d'intégrité automatiquement, mais un bug n'est jamais exclu. Si ce n'est pas critique sur un téléchargement de film, par exemple, où une ou deux frames peuvent geler ou tomber sans grande conséquence, c'est par contre vital pour une application. Donc, plutôt que de perdre un temps considérable à écrire une image non fonctionnelle, il faut rechercher le hash du fichier téléchargé, que l'on trouve habituellement sur la page des téléchargements en cliquant sur "More info".

Pour le calculer, rien de plus simple. Après téléchargement, dans le Terminal, entrez la commande:

$ shasum ~/Downloads/2014-06-20-wheezy-raspbian.zip

Et après moins d'une minute, le hash est calculé:

b020908e3cba472a24f7a17498008eb69d86d1cb  /Users/user1/Downloads/2014-06-20-wheezy-raspbian.zip

Ce qui correspond parfaitement à celui publié sur la page officielle! Pour éviter de rendre une carte SD non bootable, on s'assurera de toujours éteindre le RPi à l'aide de la commande adaptée, soit dans le terminal, soit dans l'interface graphique, et n'utiliser le bouton reset qu'en dernier recours.

Bonus: régler la taille de bloc à l'écriture

Le temps d'écriture de la carte SD ci-haut est clairement trop long, et peut l'être même avec une image parfaitement valide. En cause, bien souvent une taille de bloc inadaptée à la carte SD. La mauvaise nouvelle est qu'il n'y a pas de taille "standard": ça varie suivant le modèle d'ordinateur, de lecteur SD, de carte SD même. Heureusement Danny Guinther a monté un petit script tout simple pour connaître empiriquement la taille de bloc qui donne l'écriture la plus rapide en fonction de votre configuration.

Autre indice, la date du fichier décompressé

En regardant de plus près, il est apparu que la date du fichier .img décompressé n'était pas celle de sa création, mais bien de sa décompression! Or, les images système Linux sont ainsi (bien) faites qu'elles retiennent la date de leur création lors de la décompression. Dans l'exemple ci-dessus, si la date du fichier .img contenu dans le .zip n'est pas le 20 juin 2014, il y a de grandes chances qu'elle soit corrompue et donc non fonctionnelle, ce que le Pi ne vous dira pas facilement puisqu'il n'y a pas de BIOS capable de faire un POST comme sur un PC ordinaire. La configuration du Pi est cependant stockée dans le fichier config.txt.

Bugs étranges en cours de fonctionnement

Dans l'autre cas, le Pi est capable de booter, mais les périphériques connectés ne répondent pas comme prévu. Alors mettons que le Pi est relié à un câble réseau, soit dans un routeur soit dans l'ordinateur, mais qu'il ne répond pas quand on l'appelle avec raspberrypi.local (si vous n'avez pas imposé d'adresse IP locale comme décrit dans le post précédent). Ou vous avez effectivement branché un clavier USB, mais le témoin "Num Lock" reste éteint, alors que rien ne bouge lorsque vous tapez ou utilisez les touches fléchées. Ou une souris optique ne s'allume pas.

Par défaut, le Pi allume ses LEDs orange et verte sous la LED rouge. Si elles ne s'allument pas, alors le câble réseau n'est pas branché.

Si vous avez un hub USB doté d'une LED, la LED reste éteinte.

Tous ces signes pointent vers une alimentation insuffisante ou instable. Au démarrage du Pi, le temps de quelques secondes, tous les périphériques sont initialisés en même temps, engendrant une très grande consommation, ce qu'on appelle le inrush current. Alors s'il est vrai qu'un Raspberry Pi peut fonctionner tout seul avec une alimentation délivrant 5V sous 700mA, beaucoup d'alimentations bas de gamme ne peuvent fournir les deux en même temps, ou seront incapables de fournir brièvement un gros supplément de courant tout en maintenant la tension requise. 

Dans l'exemple qui m'a servi d'inspiration, le Pi était équipé d'un module NoIR (250mA estimés), d'un clavier Microsoft 3000 (Indiquant 100mA), connecté à une télé HDMI (50mA estimés), ce qui fait 400mA en plus du Pi lui-même, donc près de son maximum de 1A!

Il faut donc prendre bien soin de choisir une alimentation recommandée par la Pi Foundation au nom de la stabilité! Leur FAQ décrit d'ailleurs la consommation. Il faut noter aussi que tous les chargeurs de mobiles ne se valent pas; si un chargeur de mauvaise qualité est utilisé, une batterie ne sera qu'un peu plus longue à charger dans la plupart des cas, mais le Pi refusera carrément de démarrer, ou démontrera un de ces comportements.

Si vous n'avez pas de bon chargeur sous la main, il est toujours possible de brancher le Pi dans l'ordinateur comme j'ai décrit il y a quelques jours, comme leurs ports USB sont généralement mieux régulés que ceux des chargeurs. Bien sûr, un hub USB alimenté peut aussi faire une grosse différence, mais attention, certains se cantonnent à un maximum de 500mA par port, ce qui respecte scrupuleusement la norme USB 2.0.

Enfin, on peut choisir d'alimenter le RPi avec une alimentation régulée. Pas besoin d'un bidouillage monstre, une simple alimentation 5V d'au moins 1A et dotée d'une prise USB femelle correctement câblée fera le travail.