[RÉSOLU] Comportement instable brique internet v1

Bonjour,

Depuis quelques semaines je remarque un comportement instable de ma brique internet olimex (512M RAM, 1G swap).
Mise-à-jour de synaptic bug depuis l’interface web, puis synaptic désinstallée toute seule. J’ai finalement réussi à appliquer le backup pre-upgrade, puis la mettre à jour en utilisant :

Ensuite brique offline même après redémarrage. Elle s’est reconnectée après redémarrage séquentiel de mon routeur, switch puis brique.

Et aujourd’hui, alors que tout fonctionnait hier, d’abord je n’ai plus de hotspot, puis j’arrive à me connecter sur l’interface admin via le web, mais lorsque je clique sur les différents boutons j’obtiens successivement ces différentes erreurs :

Quand je clique sur mettre à jour les applications :

Impossible de récupérer la session

YunoHost a rencontré une erreur interne :/
Vraiment navré.
Vous devriez chercher de l’aide sur le forum ou le salon pour résoudre le problème, ou rapporter le bogue sur l’outil de suivi.
Les informations suivantes peuvent être utile à l’interlocuteur vous aidant :
Action

PUT /update
 {}

Trace

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/moulinette/interfaces/api.py", line 406, in process
    ret = self.actionsmap.process(arguments, timeout=30, route=_route)
  File "/usr/lib/python2.7/dist-packages/moulinette/actionsmap.py", line 495, in process
    return func(**arguments)
  File "/usr/lib/moulinette/yunohost/tools.py", line 425, in tools_update
    if not cache.update():
  File "/usr/lib/python2.7/dist-packages/apt/cache.py", line 443, in update
    raise FetchFailedException(e)
FetchFailedException: W:Failed to fetch http://ftp.fr.debian.org/debian/dists/jessie/main/binary-armhf/Packages  Hash Sum mismatch
, W:Failed to fetch http://ftp.fr.debian.org/debian/dists/jessie/main/i18n/Translation-en  Hash Sum mismatch
, E:Some index files failed to download. They have been ignored, or old ones used instead.

Mise à jour de la liste des paquets disponibles...

Quand je clique sur diagnostic :

YunoHost a rencontré une erreur interne :/
Vraiment navré.
Vous devriez chercher de l’aide sur le forum ou le salon pour résoudre le problème, ou rapporter le bogue sur l’outil de suivi.
Les informations suivantes peuvent être utile à l’interlocuteur vous aidant :
Action

GET /diagnosis
 {"locale":"fr"}

Trace

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/moulinette/interfaces/api.py", line 406, in process
    ret = self.actionsmap.process(arguments, timeout=30, route=_route)
  File "/usr/lib/python2.7/dist-packages/moulinette/actionsmap.py", line 495, in process
    return func(**arguments)
  File "/usr/lib/moulinette/yunohost/tools.py", line 612, in tools_diagnosis
    applications = app_list()['apps']
  File "/usr/lib/moulinette/yunohost/app.py", line 304, in app_list
    app_info_dict_raw = app_info(app=app_id, raw=True)
  File "/usr/lib/moulinette/yunohost/app.py", line 338, in app_info
    ret['settings'] = _get_app_settings(app)
  File "/usr/lib/moulinette/yunohost/app.py", line 1348, in _get_app_settings
    settings = yaml.load(f)
  File "/usr/lib/python2.7/dist-packages/yaml/__init__.py", line 69, in load
    loader = Loader(stream)
  File "/usr/lib/python2.7/dist-packages/yaml/loader.py", line 34, in __init__
    Reader.__init__(self, stream)
  File "/usr/lib/python2.7/dist-packages/yaml/reader.py", line 85, in __init__
    self.determine_encoding()
  File "/usr/lib/python2.7/dist-packages/yaml/reader.py", line 135, in determine_encoding
    self.update(1)
  File "/usr/lib/python2.7/dist-packages/yaml/reader.py", line 165, in update
    exc.encoding, exc.reason)
ReaderError: 'utf8' codec can't decode byte #xbe: invalid start byte
  in "/etc/yunohost/apps/hotspot/settings.yml", position 7

Et finalement elle est maintenant complètement offline.

En ssh le serveur semble répondre, mais après saisie du mot de passe il répond “permission denied”

Je suppose une carte SD corrompue. En démarrant la brique avec un écran+clavier+souris j’ai des messages d’erreur du type :

EXT4-fs error (device mmcblk0p1): ext4_mb_generate_buddy:757: group
109, block bitmap and bg descriptor inconsistent : 15665 vs 15634 free
cluster

Y-a-t-il un moyen de vérifier que c’est bien la SD qui est corrompue et pas simplement le système sans réinstaller la brique?

Tu peux mettre ta carte dans un PC et lancer un programme de détection d’erreurs. Si tu es sur Linux ou Mac, tu peux utiliser fsck (file system consistency check), sur Windows il y a CHKDSK mais je n’ai jamais testé.

Example: fsck -a /dev/mmcblk0
-a: autorepair
/dev/mmcblk0: le petit nom de ta carte micro-SD. Celui-ci est un exemple, tu devra sûrement changer ce nom.

1 Like

Bonjour,
Retour sur l’expérience “des autres” concernant un serveur sous Architecture ARM
A l’inverse d’OS comme OpenWRT (optimisé pour) qui se charge complètement en RAM et ou les accès mémoire le sont simplement pour des changements de configuration.
Les versions de distribution classique pour raspberryPi par exemple ne sont semble t-il pas chargé en RAM. Et les lectures/écritures ( notemment les LOGS !!! ) se font normalement sur les fichiers systèmes et donc la carte SD. Une carte SD n’est pas faites pour ça. Donc ça écrit constamment sur la carte. Ca c’est un premier point (trop de cycle de lecture/ecriture avec usure prématurée)
La carte SD n’étant pas faites pour ça, même sa méthode de lecture / écriture est encore plus préjudiciable à l’usure de la carte SD puisqu’elle lit et écrit par zone en modifiant une zone mémoire bien plus large que le besoin réelle. Et ça le deuxième point (une zone mémoire trop grande à réécrire par rapport au contenu réelle à écrire)
La conséquence est une usure trés rapide de la carte en peu de temps.

Des adhérents de l’association d’ILLYSE.net à Lyon en ont fait les frais plusieurs fois et sont passés sur des Pavé (Cube en x86+SATA) plutôt que des Briques (ARM+carteSD)

Alors ok ça consomme plus, mais y a quand même des configurations basse consommation en x86 et il y a beaucoup moins de problèmes de compatibilité avec les paquets.
Moi je dis ça, mais vous faites bien ce que vous voulez.
Perso en configuration x86+SATA depuis le début, je n’ai jamais eu ce genre de problème.

1 Like

En ce qui concerne ma brique Internet LIME1 + Carte SD 16Gb Transcend Premium 400x HCI 1, elle tourne depuis un an et demi avec ma boîte mail et un petit nextcloud de 4,5Gb de data, le hotspot wifi et un VPN.

Je n’ai pas de problème mais à te lire on dirait que je devrais m’inquiéter.

Je tiens au hardware le plus libre possible et à la basse consommation et en fonction de ces critères, je trouve la LIME1 d’Olimex suffisante.

Chez Neutrinet, nNous avons également de temps à autres des soucis de carte microSD qui se mettent en lecture seule ou qu’il faut vérifier avec fsck.

Du coup , est-ce qu’il existe des outils pour évaluer l’état d’une carte SD?

Pour les outils de check SD je ne sais.
Sinon il y a des contournements.
Surtout que cette carte LIME1 possède un connecteur Sata (et une NAND si tu as la bonne version)
Il pourrait être judicieux de n’avoir que le Boot sur la SD (ou la nand) et de mettre le système sur le disque Sata ou au moins déplacer le /var (avec les logs qui écrivent sans cesse) sur le disque Sata… ou encore sur un disque USB.

Salut,
quand la brique marche pas depuis plus de 12h00 malgrés de nombreux redémarrages et qu’on a ce retour est-ce que je ça signifie que je dois tout réinstaller ?
[root@localhost ~]# fsck -a /dev/mmcblk0
fsck de util-linux 2.30.2
fsck.ext2: Numéro magique invalide dans le super-bloc lors de la tentative d’ouverture de /dev/mmcblk0
/dev/mmcblk0:
Le superbloc n’a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu’il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d’exécuter
e2fsck avec un autre superbloc :
e2fsck -b 8193 <périphérique>
ou
e2fsck -b 32768 <périphérique>

Trouvé une table de partitions dos dans /dev/mmcblk0
[root@localhost ~]# e2fsck -b 8193 /dev/mmcblk0
e2fsck 1.43.5 (04-Aug-2017)
e2fsck: Numéro magique invalide dans le super-bloc lors de la tentative d’ouverture de /dev/mmcblk0

Le superbloc n’a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu’il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d’exécuter
e2fsck avec un autre superbloc :
e2fsck -b 8193 <périphérique>
ou
e2fsck -b 32768 <périphérique>

Trouvé une table de partitions dos dans /dev/mmcblk0
[root@localhost ~]# e2fsck -b 32768 /dev/mmcblk0
e2fsck 1.43.5 (04-Aug-2017)
e2fsck: Numéro magique invalide dans le super-bloc lors de la tentative d’ouverture de /dev/mmcblk0

Le superbloc n’a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu’il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d’exécuter
e2fsck avec un autre superbloc :
e2fsck -b 8193 <périphérique>
ou
e2fsck -b 32768 <périphérique>

Trouvé une table de partitions dos dans /dev/mmcblk0
[root@localhost ~]#

Il faut lancer fsck sur la partition et non pas sur la “racine” de la carte SD.
Essaye plutôt cela :

fsck /dev/mmcblk0p1

En fonction du résultat de la commande ci-dessus on verra mais une résinstallation ne sera vraisemblablement pas nécessaire.

1 Like

Je n’ai plus trouvé le temps de regarder ça depuis un moment.
J’ai branché ma microsd via un adaptateur sd sur mon pc debian. J’ai lancé un

fsck /dev/mmcblk0p1

en root et j’obtiens :

fsck de util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-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: impossible d'initialiser les drapeaux du superbloc sur /dev/mmcblk0p1


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

Finalement ma carte SD était bel et bien morte. Ma brique ne me permet pas de faire ce que je veux sans swap car la RAM est saturée aux installations d’app. Le swap a tué ma précédente sd. J’ai donc choisi de la réinstaller sur un HDD en conservant obligatoirement \boot sur une SD de 4Go qu’on m’a donnée.
J’ai détaillé le processus ici :

1 Like