Oui oui je le vois bien, je le lis aussi. Mais je t’assure, il n’y a que deux plugins a mettre a jour dans l’interface, je les montre, et core n’est pas sélectionné.
J’ai lancé un reboot, tant pis pour l’uptime, pour que ça parte sur une base saine.
Ca ne parle pas de mettre à jour core !
Non cela ne parle pas de mettre a jour le core car il n’y a pas de nouvelle version
Mais si tu laisses mettre a jour le core coché, il va le mettre et cela te permet de récupérer une version que Loic dans laquelle Loic a poussé un correctif comme il le fait parfois pour qu’on l’aie de suite et sans attendre une sortie de version
Donc je comprends pas le problème.
Vous me conseillez quoi comme taille de /tmp, parce qu’apparement, avec la v4, la taille par défaut ne passe plus (128Mb). Je ne pense pas que ça fasse partie de la config jeedom, vu que je suis en DIY, mais j’ai pas vu cette info !
en fresh install il met 256
Ok, je vais faire pareil. Avec 1Gb de mémoire vive c’est un peu chaud mais ça devrait passer !
Un raspi 2 avec une debian10 ou même avec une v4, je trouve que cela fait vraiment juste.
Un 3 devient le minimum je pense
Aucun lien avec la ram … ça prends sur le filesystem root
root@jeedom:/tmp# df /tmp
Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur
/dev/sda1 16447356 6373852 9218312 41% /
EDIT : Quoique j’ai un doute…
EDIT2 : Effectivement c’est en RAM … 
root@jeedom:/tmp# df /tmp/jeedom
Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur
tmpfs 262144 5320 256824 3% /tmp/jeedom
C’est bête ça sert à rien de mettre les fichiers de mise à jour dans le cache … Il servent pas aussi souvent que ça !
Bon, il y a quand même un soucis, même avec 256Mb de tmp:
guihome@jeedom:~ $ sudo df -Bm
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/root 20031M 4699M 14292M 25% /
devtmpfs 459M 0M 459M 0% /dev
tmpfs 464M 0M 464M 0% /dev/shm
tmpfs 464M 13M 452M 3% /run
tmpfs 5M 1M 5M 1% /run/lock
tmpfs 464M 0M 464M 0% /sys/fs/cgroup
tmpfs 256M 138M 119M 54% /tmp
/dev/mmcblk0p1 41M 23M 19M 56% /boot
tmpfs 93M 0M 93M 0% /run/user/33
tmpfs 93M 0M 93M 0% /run/user/1001
2020-12-04 11:44:09 (4.01 MB/s) - '/tmp/jeedom/install/jeedom_update.zip' saved [44976484/44976484] | OK
Cleaning folders | OK
Create temporary folder | OK
Unzip in progress
Error during update : Can not unzip fileDetails : Array
(
)
[END UPDATE ERROR]
PHP Fatal error: Uncaught Exception: Can not unzip file in /var/www/html/install/update.php:166
Stack trace:
#0 {main}
thrown in /var/www/html/install/update.php on line 166
Evidemment, vous me direz « mais décoche c’est saleté de case à cocher de mise à jour de core ». Mais je me dis que si elle est cochée, c’est pour une raison, et si ça marche pas, c’est pour une autre raison !
Et j’ai bien unzip:
unzip is already the newest version (6.0-21+deb9u2).
La case à cocher n’est pas obligatoire, c’est en fonction de ta dernière motif sur la config.
Commence par mettre à jour les plugins (sans le core) c’est pas perdu…
Oh, je suis plein d’espoir !
Uniquement que les deux plugins, voici ce que ça donne:
***************Start of Jeedom backup at 2020-12-04 11:51:43***************
Envoi l'évènement de début de sauvegarde | OK
Vérification des droits sur les fichiers | OK
Vérification de la base de données | OK
Sauvegarde la base de donnéesmysqldump: Error: 'Can't create/write to file '/tmp/#sql_2b6_2.MAI' (Errcode: 28 "No space left on device")' when trying to dump tablespaces
mysqldump: Couldn't execute 'show fields from `cache`': Can't create/write to file '/tmp/#sql_2b6_0.MAI' (Errcode: 28 "No space left on device") (1)
Erreur durant la sauvegarde : Echec durant la sauvegarde de la base de données. Vérifiez que mysqldump est présent. Code retourné : 2Détails : Array
(
[0] => Array
(
[file] => /var/www/html/core/class/jeedom.class.php
[line] => 676
[function] => require_once
)
[1] => Array
(
[file] => /var/www/html/install/update.php
[line] => 100
[function] => backup
[class] => jeedom
[type] => ::
)
)
[END BACKUP ERROR]
Error during update : Echec durant la sauvegarde de la base de données. Vérifiez que mysqldump est présent. Code retourné : 2Details : Array
(
[0] => Array
(
[file] => /var/www/html/core/class/jeedom.class.php
[line] => 676
[function] => require_once
)
[1] => Array
(
[file] => /var/www/html/install/update.php
[line] => 100
[function] => backup
[class] => jeedom
[type] => ::
)
)
[END UPDATE ERROR]
PHP Fatal error: Uncaught Exception: Echec durant la sauvegarde de la base de données. Vérifiez que mysqldump est présent. Code retourné : 2 in /var/www/html/install/backup.php:115
Stack trace:
#0 /var/www/html/core/class/jeedom.class.php(676): require_once()
#1 /var/www/html/install/update.php(100): jeedom::backup()
#2 {main}
thrown in /var/www/html/install/backup.php on line 115
guihome@jeedom:~ $ sudo df -Bm
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/root 20031M 4628M 14364M 25% /
devtmpfs 459M 0M 459M 0% /dev
tmpfs 464M 0M 464M 0% /dev/shm
tmpfs 464M 13M 452M 3% /run
tmpfs 5M 1M 5M 1% /run/lock
tmpfs 464M 0M 464M 0% /sys/fs/cgroup
tmpfs 256M 138M 119M 54% /tmp
/dev/mmcblk0p1 41M 23M 19M 56% /boot
tmpfs 93M 0M 93M 0% /run/user/33
tmpfs 93M 0M 93M 0% /run/user/1001
Bonjour,
Il semble qu’il manque mysqldump au vu des logs fournis, du coup le backup de la BDD ne fonctionne pas et ne se finit pas correctement.
Peux-tu confirmer que mysqldump est bien présent sur Debian.
mysqldump -V
Sinon pour /tmp/ qui est monté via TMPFS, tu peux commenter la ligne (TMPFS utilise de la RAM, si plus de RAM il swap) dans /etc/fstab. Dans ce cas le /tmp/ ne sera que sur ton disque sans utiliser de la RAM et du coup la limite de taille (espace disponible) est celle du / dans ton cas ~14Go. A faire en connaissance de cause.
Mon install Jeedom n’utilise pas de TMPFS pour /tmp/.
Il est bien présent, je confirme !
mysqldump Ver 10.16 Distrib 10.1.47-MariaDB, for debian-linux-gnueabihf (armv7l)
Je viens de relire les logs fournis. J’avais mal lu, mais il y a eu un soucis d’espace disque sur /tmp « encore ».
Du coup soit tu as une install Jeedom « énorme » qui explique un backup important ou beaucoup d’historique.
Du coup soit faire le tri dans les historiques pour gagner de la place, soit avoir un /tmp plus grand, soit mettre /tmp sur disque plutôt que tmpfs (comme je disais dans mon précédent post).
Le problème c’est que c’est une soucis de v4. Je n’ai jamais, de près ou de loin, eu le moindre soucis de backup pendant mes updates. Et je n’étais qu’à 128Mb.
Je pense plutôt à bonne très mauvaise idée. Utiliser tmp pour faire les backups et accélérer les choses. Ca marche quand tmp n’est pas un soucis. Ca marche quand on n’a une machine toute neuve. Si on a jeedom qui tourne depuis 2013 (? je crois) alors ça ne marche pas vraiment. Du moins c’est la conclusion à laquelle j’arrive.
Pour info mes backups faisaient 90Mb en V3. Avec la V4, ils sont passés à 110Mb.
Je ne fais pas de nettoyage, parce que je laisse faire les outils jeedom, et je conserve surtout tous les relevés de température, chauffe, humidité et compagnie, pour comparer année à année, mois à mois, et optimiser mon logement.
Pour l’instant je ne considère pas que j’ai « beaucoup » de données. C’est pas une installation toute propre, mais c’est je trouve tout à fait raisonnable.
Et je ne peux pas mettre tmp sur disque, surtout pas, ce serait une catastrophe, le cache jeedom est dessus !
Ah, et si ça a toujours été le cas cette utilisation intensive de tmp, alors soit je suis hyper chanceux jusqu’à présent, soit il y a quelque chose d’autre que je ne m’explique pas !
Et j’ai lancé un petit cleandb au cas où, pour voir si ça allège un peu la sauvegarde.
Je comprends ton point de vue, je suis comme toi un utilisateur Jeedom et oui tout n’est pas parfait. Il y a des choses surprenantes et qui fonctionne moyennement, mais il y a aussi beaucoup de chose qui fonctionne super.
Du coup je ne sais pas vraiment comment aider.
J’ai quand même une dernière idée, mettre /tmp/jeedom sur disque mais mettre /tmp/jeedom/cache en tmpfs. Avec cette solution le cache sera bien en RAM pour profiter des performances et le reste du tmp sera sur disque pour avoir de la place pour les actions de sauvegarde et autre.
Mais sinon j’avoue être à court d’idée/solution pour résoudre le soucis.
Moi, je peux bien, mais je ne sais pas comment faire! 
C’est il me semble hardcodé, c’est pas quelque chose que je peux configurer.
Mon nettoyage de base de données m’a fait perdre 1Mb.
EDIT : cette solution génére une erreur au démarrage de Jeedom (voir post en dessous)
Normalement dans le fichier /ets/fstab tu dois avoir une ligne type (il me semble car je ne l’ai pas chez moi)
tmpfs /tmp/jeedom ....
Pour moi il suffit de modifier la ligne en
tmpfs /tmp/jeedom/cache ....
Il ne faut surtout pas modifier d’autre ligne sinon ça boot plus bien ou pas du tout en fait.
Après reboot, car si tu change à chaud Jeedom ne devrai pas apprécier (désolé pour ton uptime, je sais que tu reboot rarement ton PI, comme tu le dis dans tes vidéos 
).
Pour moi il n’y a pas de risques au pire le tmpfs ne se monte pas et utilise le disque à la place. Tu pourra faire un rollback de la modification. J’espère vraiment ne pas faire planter ton Jeedom, si tu as un Jeedom de test essai d’abord dessus pour confirmer mes dires. La confiance n’exclut pas le contrôle. En plus il est tard et je fatigue. Vérifie stp avant (en testant), histoire que tu ne soit pas dans l’embarra.
Ensuite petit df -h pour vérifier que tout est comme attendu.
je vais garder cette option sous le coude, à la prochaine maj de core, si ça ne passe pas, je remonterai la problématique de manière officielle au support, et suivant leur réponse, je pense que je partirai sur la solution que tu proposes 
Bonjour,
Pour information j’ai testé sur mon Jeedom de test la solution que j’ai proposée.
Bon point de vue Linux pas de soucis pour le faire, point de vue Jeedom ça pose souci.
J’ai une erreur lors du démarrage de Jeedom
Erreur sur la restauration du cache : Erreur sur rm -rf /tmp/jeedom/cache;mkdir /tmp/jeedom/cache;cd /tmp/jeedom/cache;tar xfz /var/www/html/core/class/../../cache.tar.gz;chmod -R 777 /tmp/jeedom/cache 2>&1 > /dev/null; valeur retournée : 1. Détails : chmod: modification des droits de '/tmp/jeedom/cache': Opération non permise
Au démarrage Jeedom essai de supprimer le dossier cache, mais c’est impossible puisqu’il est défini en point de montage. Après il semble que le cache est quand même bien restauré, mais sur un Jeedom de prod avoir un message au boot c’est moche.
Du coup ce n’est pas vraiment une bonne idée de faire ce que j’ai proposé.
C’est noté ! je ne fais pas, merci de me l’avoir confirmé 