Problème Dépendances NOK

Tags: #<Tag:0x00007fa7b1c32b10>

Bonjour à tous,

J’ai réinstallé Jeedom sur une Debian 10 pour le passage en V4.1
Tout est OK sauf le plugin espeasy avec lequel je n’arrive pas à réinstaller les dépendances.
J’ai systématiquement ce message :

dependencies.sh: 59: dependencies.sh: npm: not found
chown: impossible d’accéder à ‹ node_modules ›: Aucun fichier ou dossier de ce type
Fin de l’installation

La commande whereis npm ne donnant rien, j’ai donc installer en ssh npm.
whereis npm me dit donc " /usr/bin/npm /usr/share/npm /usr/share/man/man1/npm.1.gz"

Je relance l’installation des dépendances depuis jeedom, et la il me supprime tout et me remet le meme message d’erreur, et bien sur whereis npm ne donne plus rien.

Une idée ?

Je peux au besoin fournir le log complet .

Merci d’avance

Salut PhoBo88 , j’avais eu un problème similaire avec le plugin ESPeasy sur une installation neuve buster et jeedom v4 a il y avait le plugin ESPeasy qui marché pas et je n’avait pas accès au préférence dans réglage de jeedom après avoir chercher et réinstallé jeedom plusieurs fois je me suis aperçu que je me trompé au niveau de l’installation de jeedom pour passe en root je tapé « su » et non « su - »
si je tapé « su » a la fin de l’installation il y avait toujours un erreur et sa marché pas depuis que je tape
« su - » plus d’erreur et tous fonctionne très bien
je sais pas si c’est le mème problème mais tu peut faire ça
voici un extrait d’ une doc qui l’explique tiré d’ici : [RTEX] Debian 10 - Buster - netinst - amd64 - Jeedom V4

/!\ ATTENTION : avec Buster il y a des changements par rapport à Stretch, des informations ici :
https://wiki.debian.org/NewInBuster
Ce qui est très important de souligner c’est que les commandes « su » et « sudo » peuvent ne pas avoir le même comportement que dans Stretch en fonction de l’argument utilisé. En particulier concernant les chemins par défaut de recherche des commandes systèmes.
Avec la configuration par défaut de Debian 10,
si on passe en root avec « su - » (donc avec le tiret), Le chemin contient « /usr/sbin » :

$ su -
Mot de passe :
# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Si on passe en root avec « su » (donc sans le tiret), Le chemin ne contient pas « /usr/sbin » :

$ su
Mot de passe :
# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

et dans ce cas des commandes comme usermod ou visudo sont alors introuvables.
Ces commandes sont nécessaires et utilisées par l’installation de jeedom.
Si l’installation de jeedom ne peut accéder à ces commandes, elle échoue.

Bonjour Marcoleroi,

Tout d’abord merci pour ton retour.
Je ne connaissais pas la différence entre su et su -.
Je n’ai pas d’erreur d’installation en ssh, tout va jusqu’au bout, cependant dans Jeedom le démon reste KO.
J’ai tout de même tenté avec su - mais même constat.
Une fois l’installation OK en SSH, et que je relance les dépendances à partir du plugin, rpm se supprime, et je retombe sur la même erreur :
« dependencies.sh: 59: dependencies.sh: npm: not found »

Je tourne et en rond et ne vois pas ce qui peux bloquer.
En tout cas merci d’avoir pris le temps de me répondre.

Quand tu installe jeedom tu injecte une sauvegarde ?

Oui je suis passé d’une version de Debian 9 à Debian 10.
J’ai injecté ma sauvegarde.
je ne sais pas si ça peu aider, mais j’étai en VM sur mon NAS Qnap, je suis passé sur Debian 10 en VM sur un Proxmox.

Bonsoir,PhoBoss , sur debian 9 tu était sur jeedom v3 ou v4 ? si debian 9 en v3 en essaie de passer en v4 sauvegarder puis installer debian 10 puis injecter la sauvegarde
pour moi j’ai toujours installer sur mini pc neo z64 puis z83 et VM sur nas ou Proxmox conné pas
Cdlt

Bonjour Marcoleroi,

J’étais en Debian 9 Jeedom V4.
Le fait de virtualiser ne m’a jamais posé de problèmes, je ne pense pas que le problème vienne de là, mais je préférais l’indiquer.
Je ne sais pas quoi faire, je crois que je suis bon pour attendre une update du plugin.
Si @lunarok passe par là, il aura peut-être une idée lumineuse :slight_smile:

Je viens de trouver !

Pour les personnes qui aurait le même problème, je poste la solution.
Tout simplement, en analysant une fois de plus les logs, je me suis aperçu qu’ils m’indiquaient des erreurs de sources.
J’ai effacé les sources de mon fichier situé dans /etc/apt/sources.list, et tout est passé parfaitement.

Merci encore pour aide !

Essai de le contacter directement

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.