comportement raspberry inquiétant

[acuponctus]

Bonsoir,

J'ai installé un nouveau raspberry il y a 4 mois avec non pas une carte SD mais un disque SSD connecté en USB.
J'ai procédé à l'installation sans souci.
Sauf que aujourd'hui :
j'avais domoticz en offline, alors que je connectais en ssh sur le rasp.
Puis je me suis dit, je le redémarre, et la... erreur entrée sortie lorsque je tappe reboot ou sudo reboot
idem shutdonw -r now
la seule fonction qui a pu le rebotter est reboot -f

Je fais des tests, mais des erreurs de ce type :
impossible de créer un fichier temporaire pour le « here-document » : Système de fichiers accessible en lecture seulement

puis plus tard j'ai ce message en essayant de le rebooter :
pi@raspberrypi:~/domoticz $ sudo reboot -f
Failed to read reboot parameter file: Aucun fichier ou dossier de ce type
Rebooting.

Comme si tout le disque était en lecture seule, ce qui pourrait expliquer l'ensemble des soucis.

Et ce n'est pas une question de place sur le disque car j'ai ca après le 3eme reboot :

Code : Tout sélectionner

root@raspberrypi:/home/pi/domoticz/backups/hourly# df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/root          118G    4,5G  109G   4% /
devtmpfs           460M       0  460M   0% /dev
tmpfs              464M     24K  464M   1% /dev/shm
tmpfs              464M     13M  452M   3% /run
tmpfs              5,0M    4,0K  5,0M   1% /run/lock
tmpfs              464M       0  464M   0% /sys/fs/cgroup
/dev/sda1           43M     22M   21M  52% /boot
tmpfs               93M       0   93M   0% /run/user/1000
root@raspberrypi:/home/pi/domoticz/backups/hourly#

D’après vous les prémices d'un souci matériel, mais de quelle nature : disques SSD, un composant du raspberry ?

Code : Tout sélectionner

pi@raspberrypi:~ $ reboot
Failed to set wall message, ignoring: Connexion terminée par expiration du délai d'attente
Failed to reboot system via logind: Connexion terminée par expiration du délai d'attente
Failed to open /dev/initctl: Permission non accordée
Failed to talk to init daemon.
pi@raspberrypi:~ $ reboot
Failed to set wall message, ignoring: Connexion terminée par expiration du délai d'attente
Failed to reboot system via logind: Connexion terminée par expiration du délai d'attente
Failed to open /dev/initctl: Permission non accordée
Failed to talk to init daemon.
pi@raspberrypi:~ $ sudo reboot
pi@raspberrypi:~ $ sudo su
^Csudo: unable to execute /bin/su: Input/output error
pi@raspberrypi:~ $

Seulel cette focntion le permet sudo reboot -f
mais avec un message d'erreur en sortie

Et au reboot :

Code : Tout sélectionner

login as: pi
pi@xxxxxxxx.xxxxxx.xx's password:
-bash: /etc/bash.bashrc: Input/output error
-bash: /home/pi/.bashrc: Input/output error

Merci

[lost]

Comme si tout le disque était en lecture seule, ce qui pourrait expliquer l'ensemble des soucis.

Un SSD qui se sent défaillir voit en effet son firmware le placer en mode read-only, tentative désespérée de préserver les données existantes...
Voir si un "dmesg" laisse apparaitre une tétrachiée d'IO error si le PI démarre encore.

Si aucune commande ne passe, examiner les log directement sur le stockage, connecté sur un PC Linux (Windows n'étant pas très polyglotte en matière de systèmes de fichiers), genre /var/log/messages etc...

Ca permettra aussi de vérifier si on peut ou non écrire sur le media (en tenant compte des pb de droits, ou en root).

[acuponctus]

Bonjour et merci Lost,

Le souci est que je ne peux accéder au raspberry avant 5 mois...
Et je ne peux plus me logger depuis hier soir, ca me jette une fois le mot de passe entré

Code : Tout sélectionner

login as: pi
pi@xxxxxxxx.xxxxxx.xx's password:
-bash: /etc/bash.bashrc: Input/output error
-bash: /home/pi/.bashrc: Input/output error

[lost]

Le souci est que je ne peux accéder au raspberry avant 5 mois...
Et je ne peux plus me logger depuis hier soir, ca me jette une fois le mot de passe entré

Code : Tout sélectionner

login as: pi
pi@xxxxxxxx.xxxxxx.xx's password:
-bash: /etc/bash.bashrc: Input/output error
-bash: /home/pi/.bashrc: Input/output error

Ah, c'est emmerdant en effet... Par ailleurs, attention à laisser un PI ouvert en SSH sur l'extérieur. Cela nécessite qq précautions et la première est d'en exclure l'utilisateur par défaut "pi" (même si on le conserve à usage local, la directive allowusers du /ets/sshd_config est faite pour cela) et d'en avoir configuré un autre.

Ici cette toute première précaution n'est visiblement pas prise. Alors si le reste est à l'avenant, tu as peut-être eu un autre problème!

Mes logs ssh (visibles sur /var/log/auth.log) sont en effet pleins de tentatives de connexion sur les utilisateurs pré-configurés par défaut fréquents (admin etc...). "pi" figure en très bonne place.

Avec un couple utilisateur inconnu/mot de passe à deviner, cela fait généralement 2 éléments à trouver (sauf à avoir vu une connection espionnée avec un outil d'analyse réseau au préalable, ce qui n'est pas le cas des robots tentant leur chance avec des dictionnaires/combinaisons de mots clef usuels) qqsoit la qualité du mot de passe.

Si ton PI s'est retrouvé utilisé à relayer des basses besognes, au delà des aspects légaux qui peuvent arriver (un mail de menace à Macron qui parait avoir ton PI pour origine et c'est les amis du petit déjeuner qui débarquent le lendemain matin!), son média peut avoir été rincé très rapidement par une sur-activité imprévue.

Si c'est juste un pb matériel, je ne suis personnellement pas trop pour les stockages sur USB: Pas grand chose n'est fait pour leur fiabilité (l'USB-storage est indépendant des couches logicielles sata/scsi usuelles et peu testée en dehors du cas d'utilisation classique de média extractible... ce qui peut paradoxalement poser encore plus de problèmes quand on y interface un media interne, plus encore avec certaines config noyau, type temps-réel, peu testées dans ce cadre) surtout en usage 24/7 et tant que le PI n'aura pas un M.2 natif (en format court, ce serait possible) mettre ces interfaces USB/Sata pour SSD interne peut s'avérer problématique à d'autres niveaux vs une SD dès lors qu'on a revu un peu la config pour limiter les écritures.

[acuponctus]

Merci Lost,

Le raspberry est en place depuis 4 mois en remplacement d'un ancien qui a grillé suite à un orage qui avait une carte SD (carte sd et raspberry HS) et qui a fonctionné pendant 1,5 ans.
Sinon il y a une redirection de port qui est effectuée, et le mot de passe est complexe, l'adresse IP fournie est dynamique. Je sais qu'au niveau sécurité d'accès c'est limite, cependant le risque reste faible, et je ne sais pas comment bloquer au bout de X tentatives.

J'avais choisi un disque SSD qui ne me servait plus depuis longtemps en parcourant sur les forum le souci que rencontraient beaucoup avec les cartes SD qui lachaient.
Ce raspberry est utilisé uniquement pour domoticz.

Je cherche donc un moyen pour m'y connecter sans me faire jeter, si c'est possible afin de récupérer le base de données domoticz. Je recommencerai une installation avec une carte SD et un disque SSD + clé USB afin d'avoir un maximum de sécurité le cas échéant.

Et si une astuce existe pour le remettre en état à distance, je suis preneur, il faut bien espérer...

[lost]

je ne sais pas comment bloquer au bout de X tentatives.

J'avais choisi un disque SSD qui ne me servait plus depuis longtemps en parcourant sur les forum le souci que rencontraient beaucoup avec les cartes SD qui lachaient.
Ce raspberry est utilisé uniquement pour domoticz.

(...)
si une astuce existe pour le remettre en état à distance, je suis preneur, il faut bien espérer...

Pour ce qui est de limiter les tentatives concurrentes (à pouvoir en tenter des dizaines en //, ca peut aller vite), il y a l'option MaxStartups du /etc/ssh/sshd_config, faire "man sshd_config" pour voir comment ca s'utilise. Au delà, il y a le paquet fail2ban qui peut permettre de bloquer (via le firewall) un temps donné l'accès à un serveur (dont SSH) pour une IP qui insiste au delà d'un certain nb d'échecs. C'est fait en monitorant le auth.log.

Mais cela charge pas mal les logs avec les rentatives, les banissement d'IP... J'ai ne n'ai trouvé une absolue tranquilité avec le SSH (très attaqué) que via le port-knocking pour ma part: Hors réseau local, le port SSH (22) est par défaut bloqué. Il ne s'ouvre qu'après une séquence de connections sur une série de ports (à laisser ouverts côté redirection box et FW PI en permanence, mais ne débouchant sur aucun service installé/existant) pour l'IP demandeuse seule et une durée de 30s, laissant le temps d'initier une connection SSH. Cela permet d'en rester aux mots de passe (= ne pas avoir besoin d'une machine ou on a sa clef de connection) et si on choisit bien son mode de port knocking, c'est réalisable sans forcément avoir une machine ou le "knocker" est installé: Une séquence de ping (commande assez universellement présente, y compris sur des machines que l'on n'administre pas/droits utilsateurs) fait l'affaire.

Pour le reste, sans possibilité de se logguer à distance, rien n'est envisageable. Ce serait bien de pouvoir au moins faire débrancher le PI qui tourne dans un état indéfini et pouvoir en prime avoir une chance de trouver un SSD qui permette encore d'avoir qq données exploitables pour comprendre ce qui s'est passé plus tard (ou se le faire envoyer par la poste par celui qui aura débranché).

[acuponctus]

Bonjour,

Une prise connectée à distance me permet désormais d'éteindre le raspberry.
Il a redémarré et j'ai récupéré toutes mes données.
Le souci est que celui-ci se comporte toujours de la même manière, à savoir qu'au bout de quelques heures, ou quelques jours, il plante à la "windows", le disque se verrouille en lecture seule.
Dans les logs domoticz : "attempt to write a readonly database"

J'ai testé cette commande : dmesg | tail -30
et ce qui me saute aux yeux est ceci :

Code : Tout sélectionner

[   15.432212] Under-voltage detected! (0x00050005)
.....
[   19.592090] Voltage normalised (0x00000000)
[  352.471404] Under-voltage detected! (0x00050000)
[  354.551926] Voltage normalised (0x00000000)
[  669.837186] device-mapper: ioctl: 4.39.0-ioctl (2018-04-03) initialised: dm-devel@redhat.com
[  791.006965] Under-voltage detected! (0x00050005)
[  795.169421] Voltage normalised (0x00000000)

Aussi ne serait ce pas le disque connecté en USB qui n'est pas assez alimenté ?

Comment voir l'état d'un disque en ligne de commande pour voir s'il n'y a pas un souci ?
Ca me permettra de savoir quelle pièce je dois remplacer le disque dur SSD par une carte SD + clé USB ou le raspberry.

Merci