Restauration d'une Brique suite à une carte SD corrompue

Bonjour,

J’ai une Brique qui fonctionnait bien depuis plus d’un an maintenant. C’est une LIME2.
J’ai quelques problèmes depuis deux jours, je vous mets l’historique et ce que j’ai ci-dessous :

Problème initial :

a. Après une sauvegarde en ligne de commande (sudo yunohost backup create), la Brique ne répond plus (interface web ne charge pas et terminal reste « en attente » ; en tentant de me connecter en ssh avec la commande ssh -v root@mabrique, il bloquait sur quelque chose comme « waiting for reply » indéfiniment).

b. Après un redémarrage forcé, l’interface web ne reconnaissait pas mon utilisateur, via ssh, il n’était possible de me connecter qu’en root ; il ne trouvait pas l’utilisateur admin et le précisait régulièrement lors de commande (moulinette).
Ce problème ne s’est pas reproduit depuis.

c. Après un redémarrage (reboot via session root en ssh), elle fonctionne « normalement », je peux me connecter via mon utilisateur normal, l’interface web marche, je peux me connecter en ssh en root et en admin, mais, depuis :

Symptômes récurrents :

  • Après un moment (10 minutes, 10 heures…), MySQL plante (erreur 111).
  • Si j’efface un fichier sur NextCloud, après un redémarrage de la Brique, il revient, pareil pour les notes (donc les modifications sont effacées !)…
  • TTRSS mets les flux à jour, mais ne retiens pas les modifications ; après un redémarrage, les mises à jour ont disparu.
  • L’historique bash de mes sessions ssh n’est pas enregistré.

MySQL

Quand MySQL plante, systemctl status mysql.service donne :

● mysql.service - LSB: Start and stop the mysql database server daemon
   Loaded: loaded (/etc/init.d/mysql)
   Active: active (exited) since ven. 2018-04-27 11:40:20 CEST; 47min ago
  Process: 803 ExecStart=/etc/init.d/mysql start (code=exited, status=0/SUCCESS)

Mais, si je fais systemctl restart mysql, j’ai :

Job for mysql.service failed. See 'systemctl status mysql.service' and 'journalctl -xn' for details.

systemctl status mysql.service donne alors :

● mysql.service - LSB: Start and stop the mysql database server daemon
   Loaded: loaded (/etc/init.d/mysql)
   Active: failed (Result: exit-code) since ven. 2018-04-27 12:31:05 CEST; 1min 27s ago
  Process: 7454 ExecStop=/etc/init.d/mysql stop (code=exited, status=0/SUCCESS)
  Process: 7479 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)

avril 27 12:31:05 mondomaine.tld mysql[7479]: Starting MariaDB database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
avril 27 12:31:05 mondomaine.tld systemd[1]: mysql.service: control process exited, code=exited status=1
avril 27 12:31:05 mondomaine.tld systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.
avril 27 12:31:05 mondomaine.tld systemd[1]: Unit mysql.service entered failed state.

Et, pour journalctl -xn :

-- Logs begin at ven. 2018-04-27 11:39:33 CEST, end at ven. 2018-04-27 12:40:06 CEST. --
avril 27 12:40:06 mondomaine.tld rngd[608]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
avril 27 12:40:06 mondomaine.tld /etc/init.d/mysql[9224]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
avril 27 12:40:06 mondomaine.tld /etc/init.d/mysql[9224]: [61B blob data]
avril 27 12:40:06 mondomaine.tld /etc/init.d/mysql[9224]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111 "Connection refused")'
avril 27 12:40:06 mondomaine.tld /etc/init.d/mysql[9224]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
avril 27 12:40:06 mondomaine.tld /etc/init.d/mysql[9224]: 
avril 27 12:40:06 mondomaine.tld mysql[8706]: Starting MariaDB database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
avril 27 12:40:06 mondomaine.tld systemd[1]: mysql.service: control process exited, code=exited status=1
avril 27 12:40:06 mondomaine.tld systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.
-- Subject: L'unité (unit) mysql.service a échoué
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- L'unité (unit) mysql.service a échoué, avec le résultat failed.
avril 27 12:40:06 mondomaine.tld systemd[1]: Unit mysql.service entered failed state.

(C’est moi qui remplace “mondomaine.tld”.)

Après chaque redémarrage, tout fonctionne, inclus phpMyAdmin (j’avais installé l’app il y a un moment). J’ai pu exporter les bases de données par là (pour test et au cas où).

Diagnostic

Voilà le contenu de Yunohost > Administration > Outils > Diagnostic :

{
    "host": "Debian 8.10",
    "kernel": "3.16.0-5-armmp",
    "packages": {
        "yunohost": {
            "repo": "local",
            "version": "2.7.9"
        },
        "yunohost-admin": {
            "repo": "stable",
            "version": "2.7.7"
        },
        "moulinette": {
            "repo": "stable",
            "version": "2.7.7"
        },
        "ssowat": {
            "repo": "stable",
            "version": "2.7.7"
        }
    },
    "backports": [
        "php-net-ldap3"
    ],
    "system": {
        "disks": {
            "mmcblk0p1": "Mounted on /, 58.6GiB (11.0GiB free)"
        },
        "memory": {
            "ram": "1005.4MiB (607.7MiB free)",
            "swap": "0B (0B free)"
        }
    },
    "nginx": [
        "nginx: the configuration file /etc/nginx/nginx.conf syntax is ok",
        "nginx: configuration file /etc/nginx/nginx.conf test is successful"
    ],
    "services": {
        "etherpad_mypads": "running (not-found)",
        "ynh-hotspot": "inactive (not-found)",
        "nsswitch": "inactive (not-found)",
        "fail2ban": "running (enabled)",
        "yunohost-api": "running (enabled)",
        "mysql": "running (enabled)",
        "glances": "running (enabled)",
        "rspamd": "running (enabled)",
        "rmilter": "running (enabled)",
        "avahi-daemon": "running (enabled)",
        "dovecot": "running (enabled)",
        "php5-fpm": "running (enabled)",
        "uwsgi": "running (enabled)",
        "nslcd": "running (enabled)",
        "ynh-vpnclient": "running (not-found)",
        "nginx": "running (enabled)",
        "ssh": "running (enabled)",
        "redis-server": "running (enabled)",
        "metronome": "running (enabled)",
        "postfix": "running (enabled)",
        "yunohost-firewall": "running (disabled)",
        "dnsmasq": "running (enabled)",
        "slapd": "running (enabled)"
    },
    "applications": {
        "etherpad_mypads": "Etherpad Mypads",
        "wallabag2": "Wallabag",
        "phpmyadmin": "phpMyAdmin",
        "hotspot": "Wifi Hotspot",
        "ttrss": "Tiny Tiny RSS",
        "vpnclient": "VPN Client",
        "neutrinet": "Neutrinet",
        "roundcube": "Roundcube",
        "doctorcube": "Doctor Cube",
        "nextcloud": "Nextcloud"
    },
    "security": {
        "CVE-2017-5754": {
            "name": "meltdown",
            "vulnerable": false
        }
    }
}

Carte SD

J’ai éteint ma Brique, sorti la carte SD pour la mettre dans mon ordinateur.
Je l’ai clonée, j’ai vérifié qu’elle n’est pas en lecture seule (via sudo hdparm /dev/mmcblk0 ; l’écriture est bien permise) et j’ai fait sudo fsck.ext4 /dev/mmcblk0p1 qui donne :

e2fsck 1.43.5 (04-Aug-2017)
/dev/mmcblk0p1 : récupération du journal
le drapeau needs_recovery n'est pas activé, mais le journal contient des données.
Exécuter quand même le journal<o>? oui
fsck.ext4: Unknown code ____ 251 lors de la récupération du journal de /dev/mmcblk0p1
fsck.ext4: impossible d'initialiser les drapeaux du superbloc sur /dev/mmcblk0p1


/dev/mmcblk0p1 : **ATTENTION : le système de fichiers contient encore des erreurs**

Ce qui ressemble au problème d’une autre Brique ici et soulève la même question : existe-t-il un moyen de vérifier l’intégrité d’une carte SD ? Cette erreur implique-t-elle que la carte est physiquement foutue ?

Mais, du coup, j’aimerais aussi pouvoir assez vite retrouver une Brique fonctionnelle, est-ce que le diagnostic d’une carte SD corrompue se confirme ou dois-je suivre une autre piste ?

Je me pose la question d’une restauration. J’ai les sauvegardes suivantes :

  • Sauvegarde de ± 4 Go faite via la commande yunohost backup create (qui date de juste avant les problèmes + d’autres d’une semaine avant et plus).
  • Clone de la carte SD (fait après le début des problèmes).
  • Export des bases de données MySQL via phpMyAdmin (après le début des problèmes).

a. Est-ce que ça vaut la peine de restaurer le clone sur la même carte SD ?
b. J’ai deux autres cartes SD, mais elles font 16 et 32 Go, trop petit pour le clone (64 Go). Comme j’espère mettre un disque externe sur ma Brique, je n’ai pas forcément besoin des 64 Go (il y a 53 Go de données sur ma Brique actuelle, mais la plupart de l’espace est pris par des sauvegarde de la Brique ou des fichiers sur NextCloud dont j’ai une copie).

Carte SD

Suivant cet article-ci, j’ai testé la commande badblocks -s -v -n /dev/mmcblk0 (/dev/mmcblk0 étant bien ma carte SD). J’ai plein d’erreurs d’E/S. Ce que je n’ai pas sur d’autres cartes.
(Pour mémoire : -s pour voir la progression ; -v pour voir les infos ; -n pour le mode de test en écriture non destructif (mais sauvegardes conseillées quand même).)

À noter que pour les cartes SD, cette commande n’a pas la même précision que pour d’autres supports, si j’en crois cette note ici :

While it is not usefull for creating a list of bad blocks on the SD card because SD cards do not report actual physical addresses (because of wear levelling) it does tell us if the card is broken or not.

Mais ça semble être un bon indicateur de son état…

J’ai trouvé ceci également : F3, mais comme il semble que ça détruit les données sur la carte, je n’ai pas encore essayé. Ça pourrait être utile pour « valider » une carte avant de l’utiliser (?).

3 Likes

Salut,

Je n’utiliserais plus cette carte.

Les options sont nombreuses et toute très différentes.

Cloner ton image sur une nouvelle carte microSD

Facile mais faut une nouvelle carte sd de taille identique au Mb près ou plus grande ce qui coûte des sous pour une Class 10 UHS-I Class 1 (10Mb en écriture) ou UHS-I Class 3 (45Mb en écriture).

Réduire la taille de ton image avant de cloner sur une carte SD plus petite

Pas facile et il faut de la place (2 x 64Gb) pour rester prudent et suivre ce genre de guide: Shrinking Raspberry Pi SD Card Images MAIS en prenant le temps de supprimer les sauvegardes de Yunohost pour faire de la place. Ça peut se faire au moment ou tu monterais l’image disque de ta carte avec ce genre de méthode.

Une fois l’espace disque libéré, poursuivre le plan de Shrinking Raspberry Pi SD Card Images.

Et finir par cloner le résultat sur une carte microSD plus petite en fonction de ton stock.

C’est pas simple, ce qui nous amène à cette troisième option…

Profiter de l’occasion pour tenter la combo microSD & Sata Disk

Pas facile mais le tuto de Svnet dont tu parles plus haut vaut le coup de tenter cette approche.

Au moment où tu es sensé faire le rsync, tu peux le faire depuis l’image disque de ta carte si tu la montes avant avec ce genre de méthode.

Merci pour ta réponse !

Pour l’instant, je n’ai pas de disque SATA, et comme mon image disque a été faite après les problèmes, je vais essayer de restaurer ma Brique sur ma carte microSD de 32 Go à partir d’une des archives de sauvegardes.

J’ai des petits soucis, mais je vais peut-être ouvrir un autre sujet pour ça si je trouve pas.

(Mais, en passant, j’ai essayé la méthode que tu as trouvée pour monter l’image et ça fonctionne ! :ok_hand: )

Salut,

Pour information, j’ai réussi (il y a déjà quelques semaines) à restaurer ma Brique sur la microSD de 32 Go, après plusieurs tentatives (suite à des erreurs dues à ma popote interne plus qu’à Yunohost dont la restauration est plutôt fiable pour le coup :slight_smile: ).
J’ai fait un compte rendu ici, mais c’est plus lié à mon cas de figure (Brique, corruption de fichiers, de sauvegardes), ma configuration (apps installées…) et d’être lié au VPN de chez Neutrinet et ne me semble donc pas être une manœuvre générale.

Il me reste quelques interrogations

  • Comment désactiver le backup_core_only des sauvegardes de NextCloud ;
  • Comment se débarrasser des Attention : Le fichier de configuration « xxx » a été modifié manuellement et ne sera pas mis à jour pour éviter des problèmes le jour où une mise à jour de Yunohost les modifiera ;
  • D’où vient cette erreur des locale settings ;
  • Deux ou trois choses liées à Neutrinet ;

… mais elles n’empêche pas le bon fonctionnement de la Brique. :slight_smile:

Et je reviens ici aujourd’hui aussi parce que j’ai eu une erreur de certificat Let’s Encrypt (certificat inconnu, invalide, invitation à vérifier la clé, etc. en fonction des applications).
Comme ça intervient après la restauration et que le certificat est censé se renouveler automatiquement, je ne peux pas exclure que ce soit lié, mais je ne peux pas en être sûr non plus.

Pour info :

  • La commande yunohost domain cert-status mondomaine.tld donnait :
certificates: 
  mondomaine.tld: 
    CA_type: Let's Encrypt
    summary: CRITICAL
    validity: -1
  • yunohost domain cert-renew mondomaine.tld :
Error: Certificate for domain mondomaine.tld does not appear to be correctly installed. Please run cert-install for this domain first
  • yunohost domain cert-install mondomaine.tld :
Error: The certificate for domain mondomaine.tld is not self-signed. Are you sure you want to replace it? (Use --force)
  • yunohost domain cert-install mondomaine.tld --force
Success! The SSOwat configuration has been generated
Warning: The configuration file '/etc/resolv.dnsmasq.conf' has been manually modified and will not be updated
Success! Successfully installed Let's Encrypt certificate for domain brique.pataraphe.net!

(Le “Warning” serait peut-être lié à une modification chez Neutrinet si j’ai bien compris et n’empêche pas le bon fonctionnement du machin.)

(Aussi, les lignes de commandes apparaissent en anglais, ce qui résonne avec mon incompréhension du fonctionnement des “locales settings“ (voir plus haut), mais ce n’est vraiment pas grave.)

Tout fonctionne, mais je me suis dit que ça pourrait être bien de mettre au courant du suivi ici au cas où des questions sont pertinentes (sinon tant pis :grimacing:).
(Et s’il y a des réponses pour les petites questions pas importantes, n’hésitez pas.)

Merci à @tierce pour le diagnostic et son aide rapide. :slight_smile:

2 Likes

Que dirais-tu de changer le sujet de ce fil de discussion par « Restauration d’une brique suite à une carte SD corrompue » ça me semble plus pertinent et en même tant plus positif? :blush:

2 Likes

Pour faire suite à ce message ci-dessus sur les cartes SD, j’ai testé quelques commandes et F3 sur trois cartes que j’avais (une bonne, celle corrompue de ma Brique et une corrompue d’un appareil sous Android).

Je sais pas du tout si c’est utile tout ça, mais au cas où : https://wiki.neutrinet.be/cube/tester-cartes-microsd