Etat "operation a echoué" du module de mise a jour

Utilisation du core de Jeedom Backup/Restauration
1

Ma page de gestion des mises a jour https://xxxxx/index.php?v=d&p=update m’indique avant meme que je lance quoi que ce soit une erreur « L’operation a echoué » et un pourcentage de progression a 7%. Cf capture.
La derniere fois la mise a jour du plugin « Virtual » a echoue et depuis j’ai ce message permanent.
Pas moyen de mettre a jour Virtual ou iftt, l’operation echoue.

Dans l’etat actuel, je ne suis pas confiant de tenter une migration 4.1.28 → 4.2.

Que faire pour resoudre le souci svp?

Merci

errorMaj
errorMaj1465×348 62.8 KB

2

Essaye Analyse/logs, update, vider ?

Peut tu poster le log avant ?

3

La dernière version du plugin ne nécessite t elle pas la v4.2.x…

4

Rien à voir je pense la 4.2 check si y’a pas déjà une update en cours mais apparemment faut qu’on améliore ça.

5

Si, la mise à jour du plugin ne passe pas en 4.1.
Par contre, la mise à jour du core en 4.2 mets à jour le plugin

6

Dc le plugin necessite la v4.2 ?

7

J’ai eu le même problème.
J’ai mis à jour le core en 4.2 et le plugin a été mis à jour tout seul

8

Dc le plugin necessite la v4.2.
C’est bien ce que je dis

9

Y’a pas que ça pour ça que j’aimerai avoir le log …

10

Oui c’est le même « soucis » que j’avais remonté. Vide tes log update et ça va passer.

11

Je pense avoir corrigé en alpha, à suivre …

12

Alors je n’ai pas de log particulier pour l’erreur. Ce qu’on voit dans le log update c’est celui d’un nouvel essai (on ne sait jamais) d’update de virtual

[2022-02-04 12:48:19][ALERT] : [START UPDATE]
[2022-02-04 12:48:19][ALERT] : Début de la mise à jour de : virtual
[2022-02-04 12:48:19][ALERT] : Action de pré-update...
[2022-02-04 12:48:20][ALERT] : OK
[2022-02-04 12:48:20][ALERT] : Téléchargement du plugin...
[2022-02-04 12:48:20][ALERT] : Téléchargement de virtual...
[2022-02-04 12:48:20][ALERT] : URL https://market.jeedom.com/core/php/downloadFile.php?id=21&version=stable&jeedomversion=4.1.28&hwkey=xx&username=xx&password=xx&password_type=sha1
--2022-02-04 12:48:20--  https://market.jeedom.com/core/php/downloadFile.php?id=21&version=stable&jeedomversion=4.1.28&hwkey=xx&username=xx&password=xx&password_type=sha1
Resolving market.jeedom.com (market.jeedom.com)... 51.210.253.116, 51.178.69.128
Connecting to market.jeedom.com (market.jeedom.com)|51.210.253.116|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 83 [text/html]
Saving to: '/tmp/jeedom/market/virtual.zip'
0K                                                       100% 1.32M=0s
2022-02-04 12:48:20 (1.32 MB/s) - '/tmp/jeedom/market/virtual.zip' saved [83/83]
[2022-02-04 12:48:20][ALERT] : OK
[2022-02-04 12:48:20][ALERT] : Echec lors du téléchargement du fichier. Veuillez réessayer plus tard (taille inférieure à 100 octets). Cela peut être dû à une absence de connexion au market (vérifiez dans la configuration de RPI 3 B qu'un test de connexion au market marche) ou lié à un manque de place, une version minimale requise non consistante avec votre version de RPI 3 B un souci du plugin sur le market, etc.
[2022-02-04 12:48:20][ALERT] : [END UPDATE ERROR]

Peut etre faut-il changer le niveau de log pour update mais je vous avoue que je ne me souviens plus ou on doit le changer

13

c’est bien çà qui m’intéressait :upside_down_face:

14

oui mais ca n’est pas affiche au moment ou je fais le display de ma page update, mais au moment de faire l’update virtual lui meme.
Ceci etant, le vidage de logs permet effectivement de supprimer le bandeau rouge, merci!

15

Bonjour, j’ai le même problème depuis des semaines. Je suis en 4.1.16 mais le plugin virtual est en beta.
Merci.

16

Vider le log update et ça devrait être ok

17

Non ça ne change rien
Edit : même message et bandeau rouge quand je clique sur " Réglages → Système → Centre de Mise à jour" mais là ça disparait en vidant les logs (le bandeau)

18

Oui c’est ça y un message dans le log update qui fait ça. C’est quand on cherche a installer une maj comme virtuel par exemple qui n’est plus compatible 4.1

19

En fait j’étais dans mise à jour du core sur github/ j’ai corrigé par stable, je vais passer en 4.2, le temps de faire un backup de ma VM sous Proxmox (en espérant que ça ne nique pas mes scénarios pour le chauffage, j’utilise Framework sc v0.992c).
Edit : bon ben beau plantage de l’update

Check rights...PHP Fatal error:  Uncaught Error: Call to undefined method jeedom::cleanFileSystemRight() in /var/www/html/install/update.php:78

Et la méthode manuelle ici c’est pire que mieux : https://doc.jeedom.com/fr_FR/howto/jeedom.mise_a_jour_manuel

Edit : j’ai viré la ligne dans update.php. Mais bon ça bugue + consistency.php pareil, en recommençant plusieurs fois j’y suis arrivé.

20

Bonjour à tous,

je ne sais pas si ça peut aider mais de mon côté, je suis en train de tenter une mise à jour de 4.0 vers 4.2 et j’ai la fameuse erreur sur l’update.php en ligne 78 : « Error: Call to undefined method jeedom::cleanFileSystemRight() » qui me bloque dès le démarrage.

Je me suis aperçu que dans les autres fichiers qui réalisent cette étape, comme le consistency.php, la méthode appelée était cleanFileSytemRight(), (sans le « s » à System).
Il y a peut-être une piste sur cela.
J’ai supprimé le « s » dans l’update.php.

Mais si j’active le pre-update à la mise à jour du core, j’imagine qu’il met à jour à nouveau l’update.php avec le « s » dans l’appel à la méthode.

Je viens de retenter en remodifiant mon update.php, et en désactivant le pre-update. Ca s’est bien lancé.
Cependant, le consistency.php a du se mettre à jour lors de l’install est a lui aussi planté pour la même erreur.

J’ai donc relancé la mise à jour, et là, tout s’est bien passé sans erreur.

Il faudrait donc peut-être conseiller aux utilisateurs qui souhaitent mettre à jour depuis une ancienne version vers 4.2 de ne pas faire le pre-update dans un premier temps, et de relancer ensuite si ça plante au consistency.php?

Au passage, merci à tous pour vos contributions et le travail effectué sur Jeedom.

Cordialement