Retex passage debian 12 sur ATLAS

Bonjour à tous

Retour d’expérience sur passage en DEBIAN 12 sur mon ALTAS en 11.3, jeedom 4.5.3

je récupères les 2 images 11 et 12 sur : Index of /atlas

je mets le fichier de la 12 et le renomme conformément aux instruction : (/var/www/html/install/update/JeedomSystemUpdate.img.gz)

je lance la page de RECOVERY et je me retrouve en 11.11

Avec changement de l’adresse IP de mon jeedom puisque l’adresse MAC change.

donc 1er connerie, si vous voulez passer de la 11 à la 12, après avoir mis le fichier faut juste rebooter et ne pas passer par la page de RECOVERY qui ira chercher le dernière version 11.

Je remets le fichier de la 12 en place et je reboot

Démarrage en DEBIAN 12 et jeedom 4.5.2

je passe la maj 4.5.3

je remet mon fichier de backup

je restaure mon fichier

J’en suis là avec pas mal d’erreur sur le plugin : 15 erreurs, maintenant 13 (sans rien avoir touché)

je laisses les dépendances se relancer en auto

ZIGBEE :

Le démon z2m ne démarre pas car démon MQTT pas démarré

Les dépendances sont OK pour MQTT, je démarre le démon à la main

Le démom z2m démarre tout seul = ZIGBEE OK

ZWAVEJS :

dépendances KO, démon KO

> zwave-js-ui@11.15.1 start
> node --preserve-symlinks server/bin/www.js
node:internal/modules/package_json_reader:314
throw new ERR_MODULE_NOT_FOUND(packageName, fileURLToPath(base), null);
^
Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'jsonfile' imported from /var/www/html/plugins/zwavejs/resources/zwave-js-ui/server/lib/jsonStore.js
at Object.getPackageJSONURL (node:internal/modules/package_json_reader:314:9)
at packageResolve (node:internal/modules/esm/resolve:767:81)
at moduleResolve (node:internal/modules/esm/resolve:853:18)
at defaultResolve (node:internal/modules/esm/resolve:983:11)
at #cachedDefaultResolve (node:internal/modules/esm/loader:731:20)
at ModuleLoader.resolve (node:internal/modules/esm/loader:708:38)
at ModuleLoader.getModuleJobForImport (node:internal/modules/esm/loader:310:38)
at ModuleJob._link (node:internal/modules/esm/module_job:182:49) {
code: 'ERR_MODULE_NOT_FOUND'
}
Node.js v22.22.0

Je relance les dépendances à la mano

Les dépendances sont OK, même si le log ci-dessus (que j’avais vider avant de relancer) est de nouveau présent, relance démon OK

Plus que 5 Plugins NOK :slight_smile:

Relance manuel des dépendances et démons pour les 5 plugins restant ;

jeewhatsapp : OK

mirobot : OK

apcups :OK

ttscast : OK

worxLandroidS : OK

Pour Conclure :

La procédure s’est bien passée, hormis MA boulette pour la prise en compte du fichier DEBIAN 12, c’est nickel.

Contrairement à ce que je pensais après un premier tour rapide, j’ai perdu toutes les valeurs qui étaient en cache :frowning:

Merci à l’équipe Jeedom pour le boulot !

je reste en surveillance

je remarque une erreur sur mon dashboard :

http://192.168.1.15/index.php?v=d&p=view	0	Erreur de directive Content Security Policy sur la ressource "https://fonts.gstatic.com/s/audiowide/v7/l7gdbjpo0cum0ckerWCdlg_O.woff2"

Ca doit venir d’un de mes widgets, je creuse

Mon réseau ZIGBEE fonctionne pas… tout semble pourtant OK mais aucun module ne remonte ses infos…

1 « J'aime »

Bonjour,

pour jeezigbee et zwavejs il est préférable d’utiliser le port usb de type /dev/serial/by-id.

akenad :slight_smile:

1 « J'aime »

Bonjour Akenad

La clé zwave est en externe sur le port USB, j’ai toujours eu cette conf : /dev/ttyusb0

c’est quoi la différences avec les ports en /de/serial ? et comment connaitre l’id ?

Pour éviter ta boulette tu aurais dû suivre mon tuto :smiley:

1 « J'aime »

Oui en effet, j’aurais du :wink:

Vous avez aussi perdu tout les positions des commandes infos ? il me semble qu’il n’y avait plus ce problème avec la nouvelle gestion du cache ?

Je te rassure même avec mon tuto j’y arrive pas : j’ai bien mis le fichier au bon endroit et avec le bon nom mais malgré le redémarrage l’install ne se lance pas…

A bon, ca a bien fonctionné chez moi avec le reboot. tu as respecté la case dans le nom du fichier ?

J’ai l’impression que oui pourtant :

Je vais passer par la clé USB comme j’avais deja testé précédemment.

Oui ca semble bon pourtant

J’ai ptet un fichier .log dans le même répertoire mais qui est caché ? Cependant l’option pour afficher les éléments cachés dans l’explorateur de fichiers n’est pas activable :frowning: .

J’ai lancé la méthode USB et ça fonctionne direct…

1 « J'aime »

faut aller voir en ssh sinon

Oui… Sur les premières images système mises à disposition en septembre 2025 il pouvait y avoir ce souci lors d’une restauration système automatique. Il existe une 1ère partition sur l’EMMC mais qui n’est pas montée sur le système final. Le souci était que dans certaines circonstances le fichier de log pouvait y être écrit malgré tout obligeant donc à passer par la méthode USB par la suite. Ce point a été corrigé rapidement mais je pense que tu es dans ce cas surtout que de mémoire tu avais testé rapidement après la mise à disposition de cette procédure.

La solution la plus simple est de réécrire le système via une clé USB comme tu viens de le faire.

L’autre solution, plus technique, est de supprimer ce fichier en ligne de commande (en root) :

mount /dev/mmcblk0p1 /mnt
rm -f /mnt/JeedomSystemUpdate.log
umount /mnt
2 « J'aime »

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