Depuis presque un an et demi que je possède un Raspberry Pi, j’ai rencontré tout un tas de crashs inopinés de la bête au fur et à mesure des installations softwares et hardwares.
Vous trouverez ci-dessous quelques astuces qui vous permettront de résoudre ou de contourner les problèmes.
Le choix de la carte SD ou Micro-SD pour votre Raspberry Pi est TRES important.
Le site ci-dessous référence toute une série de cartes et indique leur compatibilité avec le Pi :
http://elinux.org/RPi_SD_cards
Préférez acheter une carte authentique de marque connue dans une enseigne réputée plutôt que d’en acheter une, peut-être contrefaite, sur eBay ou AliExpress.
Ce blog donne quelques exemples : http://blogmotion.fr/diy/carte-sd-rpi-12174
Dans la même veine, je suis récemment tombé sur un article expliquant que les constructeurs de smartphones Androïd commençaient à supprimer le port SD de leurs appareils car les utilisateurs y insèrent des cartes bas de gamme et les incriminent ensuite quand les problèmes de corruption des données surviennent.
http://www.phonandroid.com/hugo-barra-explique-pourquoi-xiaomi-pas-port-microsd-smartphones.html
Là encore, il convient de bien choisir son alimentation.
Bien que le Raspberry Pi se contente d’une puissance allant de 1W à 3,5W en fonction du modèle, il ne faudra pas hésite à choisir une alimentation légèrement surdimensionnée qui permettra de brancher quelques périphériques USB sans nuire au bon fonctionnement de la carte.
On évitera tout ce qui est chargeur GSM/Smartphone qui ne délivrent généralement que 500mA.
Et là aussi, les chinoiseries sont à proscrire. Il vaudra mieux investir quelques euros de plus dans une alimentation sérieuse plutôt que de voir son Pi planter régulièrement parce que le transfo n’est pas capable de maintenir une tension constante de 5V.
Dans cette vidéo Youtube, le gars explique comment mesurer la tension du Raspberry Pi en charge (en fonctionnement) :
La mesure s’effectue entre TP1 (+) et TP2 (-) :
Référence : http://raspbian-france.fr/accessoires-raspberry-pi-2/
J’avais un petit souci de retour d’alimentation dans le Raspberry Pi par les connecteurs USB A.
En effet, mon disque dur externe, qui possède sa propre alimentation 5V, demandait un ordre d’allumage précis pour fonctionner correctement (cfr. article).
De même, je le suspectais de provoquer des variations de tension sur le Pi lors de ses démarrages en sortie de veille.
En suivant les conseils de cet article (http://stevenhickson.blogspot.be), j’ai recouvert la broche + de la fiche USB pour résoudre le problème.
La broche + se trouve à droite lorsque l’on regarde la fiche de face :
On découpe un petit morceau de tape isolant selon les dimensions reprises sur l’image ci-dessous :
Et on le colle de manière à recouvrir complètement la broche jusqu’au fond de la fiche :
Attention :
J’ai effectué la même opération sur un HUB USB qui présentait le même problème et ça a fonctionné.
Par contre sur un autre HUB USB qui ne présentait pas de « power feedback », ça n’a pas fonctionné. Il n’était même plus reconnu par l’OS.
En effet, le périphérique étant électriquement bien séparé entre USB in et USB out, la partie amont devait être alimentée par le Pi pour fonctionner alors que la partie aval recevait son énergie du transfo.
Lorsque l’on possède un Raspberry Pi, il est tentant d’y installer Transmission et, ainsi, le transformer en SeedBox qui partagera des fichiers Torrents 24/7.
Si, comme moi, vous partagez tout un tas de distributions Linux qui génèrent un trafic constant important, vous risquez de voir votre Pi se planter tous les 3 ou 4 jours.
En cause, un problème de gestion de la mémoire que l’on pourra résoudre comme expliqué ci-dessous.
Le pilote réseau du RPi peut parfois avoir du mal à gérer un trafic intense sur les ports USB et le port Ethernet, surtout en cas d’utilisation importante du processeur. Il peut ainsi perdre la trace de connexions et, dans certains cas, saturer la mémoire et crasher.
Pour résoudre ces problèmes on utilisera ces méthodes :
Les crashs système sur le Raspberry Pi proviennent souvent d’une mauvaise gestion de la mémoire vive.
La commande free
peut nous donner un aperçu de sa répartition :
$ free -h
Le paramètre -h
permet d’afficher les données selon l’unité la plus concise pour la lecture humaine.
$ free -h total used free shared buffers cached Mem: 974M 492M 482M 0B 25M 241M -/+ buffers/cache: 224M 750M Swap: 99M 0B 99M
man free
indique que shared peut être ignoré car d’utilisation obsolète.Dans certains cas, notamment lors de l’utilisation de Transmission, si la taille du cache utilise presque toute la mémoire vive et que de la mémoire libre est rapidement nécessaire, il est possible que le kernel se crash.
Il est possible de libérer manuellement de la mémoire cache pour retrouver de la mémoire libre (si le noyau Linux est plus récent que le 2.6.16) en procédant comme suit :
$ echo 1 > /proc/sys/vm/drop_caches
$ echo 2 > /proc/sys/vm/drop_caches
$ echo 3 > /proc/sys/vm/drop_caches
Les commandes précédentes doivent être exécutées en tant que root
(su). Si vous voulez les exécuter en sudo
, vous devez utiliser cette syntaxe :
$ sudo sh -c 'echo 1 >/proc/sys/vm/drop_caches' $ sudo sh -c 'echo 2 >/proc/sys/vm/drop_caches' $ sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'
Le résultat après avoir envoyé « 3 » dans drop_caches
:
total used free shared buffers cached Mem: 974M 326M 648M 0B 1,3M 103M -/+ buffers/cache: 221M 753M Swap: 99M 0B 99M
On peut décider de vider la mémoire cache (par exemple toutes les heures) en incluant l’une des commandes ci-dessus dans le cron
.
Source : https://unix.stackexchange.com
Afin d’empêcher la mémoire cache de trop empiéter sur la mémoire libre et de la réduire à peau de chagrin, il est possible de définir la taille minimum de cette dernière.
On édite le fichier sysctl.conf
:
$ sudo nano /etc/sysctl.conf
Et on modifier la ligne :
vm.min_free_kbytes = 8192
En :
vm.min_free_kbytes = 32768
Et on relance :
sudo sysctl -p
Les valeurs sont données en ko. On passe ici de 8Mo à 32Mo.
Source : http://stevenhickson.blogspot.be
On peut rencontrer cette erreur dans les fichier de log suivant :
smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
/var/log/messages
/var/log/kernel
/var/log/dmesg
L’erreur ci-dessus peut être évitée en demandant au noyau de désactiver le mode « Turbo Réseau ».
Pour ce faire, nous allons editer le fichier /boot/cmdline.txt
:
$ sudo nano /boot/cmdline.txt
Et y ajouter ce bout de code à la fin de la ligne :
smsc95xx.turbo_mode=N
Ce qui pourrait donner quelque chose comme ceci :
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p6 rootfstype=ext4 elevator=deadline rootwait smsc95xx.turbo_mode=N
Source : https://raspberrypi.stackexchange.com
Le principe est de limiter la vitesse de téléchargement et le nombre de Torrents simultanés.
On va éditer le fichier de configuration de Transmission :
$ sudo nano /etc/transmission-daemon/settings.json
Et on va modifier les entrées suivantes comme ceci :
"peer-limit-global": 80, "peer-limit-per-torrent": 20,
"speed-limit-down": 500, "speed-limit-down-enabled": true, "speed-limit-up": 10, "speed-limit-up-enabled": true,
Ces valeurs sont très basses et il conviendra de les adapter à votre usage.
Sources : https://www.fanjoe.be