Les Raspberry Pi et les microSD
Les Raspberry Pi allumés h24 sont des tueurs de cartes microSD. Petite histoire d'hier soir.
Je lance un apt-get update / upgrade sur le Zero 2 WH de mon Jukebox Pioneer et je remarque que c'est affreusement lent mais cela aboutit. Toutefois un simple uptime en SSH mettait 1 minute à répondre sur le terminal, c'est bien trop long. Rien dans le dmesg. Dans la foulée j'overclocke un peu en modifiant le /boot/config.txt, histoire d'être symétrique avec le Raspi collé à mon Linky. Au reboot le Raspi ne répond plus en SSH (connection timed out).
Démontage du jukebox et je sors le petit écran portable USB. Le Raspi ne boot plus du tout, pas de LED verte qui clignote, écran noir. Je prends la carte microSD et dans deux lecteurs USB différents sur mon PC Windows elle n’apparaît pas (Gestionnaire de disque). Qui ne tente rien n'a rien, après un petit coup de station à air chaud à 230°C (20-30 secondes) la carte devient à nouveau lisible.
Je la dump rapidement dans un fichier .img avec Win32 Disk Imager sans erreur de lecture à priori. Fichier que j'ai injecté dans un second temps sur une autre carte. Avec la nouvelle carte (une autre Sandisk Ultra 16Go - même modèle) ça boote, mais le raspi est instable, il plante de manière aléatoire durant la phase systemd en faisant des freeze et des Kernel Panic. Impossible d'avoir la console.
Même chose si je remets la carte "ressuscitée".
Un problème d'alim ? Non. En fait ne mettez jamais 11Ghz comme valeur de fréquence ARM dans le /boot/config.txt. Et oui il y a un zéro en trop.
Comme la carte a été clonée, la valeur foireuse a été clonée elle aussi. Une fois la valeur passée de 11000 à 1100 (Mhz) c'est à nouveau stable.
J'ai remis l'ancienne carte, mais bien que ramenée à la vie par l'air chaud, elle est toujours anormalement lente par rapport à l'autre -> direction DEEE.
Que ce soit Samsung ou des Sandisk ça s'use.
Je lance un apt-get update / upgrade sur le Zero 2 WH de mon Jukebox Pioneer et je remarque que c'est affreusement lent mais cela aboutit. Toutefois un simple uptime en SSH mettait 1 minute à répondre sur le terminal, c'est bien trop long. Rien dans le dmesg. Dans la foulée j'overclocke un peu en modifiant le /boot/config.txt, histoire d'être symétrique avec le Raspi collé à mon Linky. Au reboot le Raspi ne répond plus en SSH (connection timed out).
Démontage du jukebox et je sors le petit écran portable USB. Le Raspi ne boot plus du tout, pas de LED verte qui clignote, écran noir. Je prends la carte microSD et dans deux lecteurs USB différents sur mon PC Windows elle n’apparaît pas (Gestionnaire de disque). Qui ne tente rien n'a rien, après un petit coup de station à air chaud à 230°C (20-30 secondes) la carte devient à nouveau lisible.Je la dump rapidement dans un fichier .img avec Win32 Disk Imager sans erreur de lecture à priori. Fichier que j'ai injecté dans un second temps sur une autre carte. Avec la nouvelle carte (une autre Sandisk Ultra 16Go - même modèle) ça boote, mais le raspi est instable, il plante de manière aléatoire durant la phase systemd en faisant des freeze et des Kernel Panic. Impossible d'avoir la console.
 |
 |
 |
Même chose si je remets la carte "ressuscitée".
Un problème d'alim ? Non. En fait ne mettez jamais 11Ghz comme valeur de fréquence ARM dans le /boot/config.txt. Et oui il y a un zéro en trop.
Comme la carte a été clonée, la valeur foireuse a été clonée elle aussi. Une fois la valeur passée de 11000 à 1100 (Mhz) c'est à nouveau stable.
J'ai remis l'ancienne carte, mais bien que ramenée à la vie par l'air chaud, elle est toujours anormalement lente par rapport à l'autre -> direction DEEE.
Que ce soit Samsung ou des Sandisk ça s'use.
