Wifi acolab en panne ? Impossible d'obtenir l'adresse IP

Aujourd’hui 13h45 :frowning:

Jai tout essayé de ce que jai pu trouver sur le net de mon coté (reboot telephone, changement nom d’appareil…)

On dirait que seul un reboot routeur pourrais lui redonner vie ?

De passage à Clermont je suis passé voir et le pi de l’acolock n’a pas l’air de vouloir booter. J’ai essayé une autre alim et même résultat. Je n’ai malheureusement pas le temps de regarder plus.

J’ai réactivé le DHCP sur le routeur pour avoir accès à internet au local, mais l’ACoLock ne fonctionne pas.

@mike, je suis entrain d’essayer de refaire une µSD pour l’ACoLock.

N’étant pas au local, j’ai un doute sur la configuration du truc. Il me semblait que le DHCP était fait par l’ACoLock. Dans la notice d’install tu parles de régler le DHCP : lequel celui de l’ACoLock ou du routeur ?

Je n’avais pas mis à jour cette partie après l’avoir configuré en DHCP. Je viens de corriger le README. Il faut mettre le Pi en IP fixe.

Il faudra redéclarer tous les accès, non ?

Oui mais si l’ancienne carte SD est toujours opérationnelle on peut récupérer les anciens. C’est possible que l’ancienne carte fonctionne d’ailleurs. Je ne sais pas ce qui bloque le boot.

Le fichier à récupérer pour les accès c’est /home/pi/back/acolock.sqlite.

La partition rootfs est corrompu. Je tente une réparation avec fsck.ext4 pour voir…

J’ai reussi à installer ansible-playbook -i ansible/hosts ansible/site.yml par contre le app.yml echoue car il ne trouve par yarn (sur mon PC si j’ai bien compris).

J’ai essayé d’installé yarn mais meme après l’install la commande n’est pas reconnu. De plus je pense qu’il va y avoir un problème de version v1 vs v2.

Je suis arrivé au bout de mes compétences sur le sujet. @mike, peux tu faire quelque chose ?

L’accès à distance semble fonctionner mais il faudrait juste autoriser ma clé ssh. À partir de là je dois pouvoir finir l’installation oui.

Petite question depuis combien de temps l acoloc tourne ?
Ça permet d avoir une idée de la duree de vie de la carde sd.
Et soi prevoir un clone ( a maintenir a jour) ou un nas (que je peux donner j ai un vieux ds211j) qui gere tte la fonction dhcp et autentification le rpi ne servira que pour le pilotage des moteurs.
Apres je n ai pas suffisamment de competence pour voir si c est faisable.

Début 2019.

La carte est probablement plus vieille.

Ça permettrait d’avoir le DHCP (et donc l’accès à internet) indépendant, mais ça ne ferait pas plus marcher l’acolock si le pi tombe en panne.

Pour avoir un truc plus fiable il faudrait sans doute une solution plus simple avec un microcontrolleur, mais dans ce cas il faut changer l’interface (une appli mobile au lieu d’une appli web, par exemple, ou un système matériel). Ou alors rester sur un Linux complet, mais sur une architecture plus fiable.

La réinstallation du pi a été finalisée à distance. Je devrais pouvoir passer au local demain pour vérifier que ça fonctionne.

Comme on a perdu l’ancienne carte µSD, il faut recréer les comptes de tout le monde. Je peux le faire à distance. Pour ceux qui avaient accès avant, envoyez moi un message privé pour que je vous recréé un compte et vous communique le mot de passe.

Et un hdd sur le rpi j ai plein de 2.5p de petite capacité ?

Si non pour expliqué au non informaticiens, comment une carte SD fini t’elle corrompu ? Elle a touché des pots de vin ? Cest pas le Covid !

2 J'aimes

Il y a deux moyens, en excluant les pots de vin :wink: :

  • Les ‹ cases › mémoires (le silicum) d’une carte SD ‹ s’usent › lors des cycles d’écriture. Il arrive donc un moment où elle ne retient plus l’informaton qu’on lui à confié. C’est l’Alzhimer de la ‹ case › mémoire :crazy_face: . Du coup comme l’information est perdue, le système de fichier n’est plus ‹ intègre › et donc tu perds des informations.

  • Une coupure d’alimentation lors d’une phase d’écriture peut laisser la carte dans un état ‹ indéfini ›. Car lorsque l’OS veut écrire sur la carte, en fait ce n’est pas lui qui le fait directement. Il demande au contrôleur de la carte de le faire. Pour limiter l’usure décrite si dessus, ces phases d’écritures sont regroupés. Si la coupure se fait entre le moment où l’OS a demandé au contrôleur d’écrire et le moment où l’écriture est vraiment faite => le système de fichier n’est plus ‹ intègre ›.

Voilà l’état de mes connaissances sur le sujet

:wave: merci :+1:

Il me semble que ce problème est résolu sur les systèmes de fichier journalisés (comme ext3 et ext4 par exemple). Ils se débrouillent pour que le système de fichier soit toujours dans un état intègre, même si les instructions ne sont pas toutes passées.

L’ACoLock est de nouveau opérationnel ! :tada:

3 J'aimes