Impeccable, le Recovery Mode ne fonctionne pas…
la box redémarre, apparait tout de suite sur mon réseau, et même message d’erreur quand je veux y acceder
Non, il faut libérer l’espace disque.
Avez-vous encore l’accés en ssh pour vérifier l’espace disque disponible ?
Vous avez un fichier de 1.3 Go à supprimer : /var/www/html/DB_backup.sql
Il faut aussi rechercher les répertoires anormalement gros et supprimer les fichiers non utilisés.
J’ai uploadé le fichier DB_backup.sql sur le pc et je l’ai effacé de la smart, sans résultat.
Je regarderai ça demain matin en rentrant du boulot, ou ce week-end.
bon, impossible d’acceder à jeedom, toujours le message SQLSTATE[HY000] [2002] No such file or directory
je vais dormir, j’y passe pas la journée comme hier apres une nuit de boulot!
J’ai tant bien que mal fait un « Recovery Mode » et je suis en cours de remonté de backup, avec des messages d’erreur qui apparaissent dans le centre de messages
La remonté de sauvegarde a l’air de planter.
[MySQL] Error code : 42S02 (1146). Table ‹ jeedom.user › doesn’t exist : SELECT id, login, profils, password, options, rights, enable, hash FROM user WHERE id=:id:
ça va être fin de chantier entre Jeedom et moi.
Bonjour @JcNantes ,
Vous avez résolu le problème de base qui est l’espace disque disponible très faible ?
Avec une Smart, vous pouvez ouvrir une demande de support auprès de Jeedom en vous connectant sur le market.
Non ce n’est pas résolu, car après avoir vidé toute la table « history » je me suis trouvé avec un espace dispo de 0% > Plantage.
Au moins on a trouvé ce qui occupait de la place, c’est ces fameux « anciens » historiques qui n’ont jamais été effacés de la bdd par Jeedom. (il y a 30100107 lignes!)
Il faut commencer par résoudre le pb de l’espace disque faible/nul qui empêche le démarrage normal de Jeedom.
Donc connexion en ssh ( ou branchement écran et clavier sur la box ) et recherche des répertoires de taille anormale.
La commande:
sudo du -s /* | sort -rn
Le résultat sur ma Smart pour que vous puissiez comparer:
1946836 /var
1792076 /usr
262148 /swapfile1
114360 /root
103121 /media
100064 /lib
34924 /run
30956 /opt
8824 /tmp
7864 /bin
6296 /etc
4988 /sbin
56 /home
Le résultat de mon df -h :
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev 732M 0 732M 0% /dev
tmpfs 172M 35M 138M 20% /run
/dev/mmcblk0p7 6,5G 4,1G 2,1G 67% /
tmpfs 859M 0 859M 0% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 859M 0 859M 0% /sys/fs/cgroup
tmpfs 256M 8,0K 256M 1% /tmp
tmpfs 128M 8,7M 120M 7% /tmp/jeedom
/dev/mmcblk0p1 253M 101M 152M 40% /media/boot
C’est la table « history » qui comporte trop d’enregistrements.
J’ai ouvert un ticket pour savoir comment effacer ces enregistrement « proprement », car la, ça dépasse mes compétences.
Finalement la restauration du mon backup s’est bien passé malgré les erreurs affichées.
Merci à Mips et jpty pour votre aide, ça m’a permis de trouver d’ou venait le manque d’espace disque.
J’ai ouvert un ticket pour savoir comment supprimer « proprement » tous ces enregistrements, remontant à 2016 avec un enregistrement toutes les secondes, inutiles dans la table « history ».
Filesystem Size Used Avail Use% Mounted on
udev 732M 0 732M 0% /dev
tmpfs 172M 22M 150M 13% /run
/dev/mmcblk0p7 6.5G 5.5G 630M 90% /
tmpfs 859M 0 859M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 859M 0 859M 0% /sys/fs/cgroup
tmpfs 256M 4.0K 256M 1% /tmp
tmpfs 128M 4.0M 125M 4% /tmp/jeedom
/dev/mmcblk0p1 253M 101M 152M 40% /media/boot
Table Size (MB)
history 1600
historyArch 152
Bon finalement, j’ai pas réussi à attendre la réponse au ticket.
J’ai réussi tant bien que mal à vider les tables « history » et « historyArch »
Lors de ma première tentative, plus je vidais et plus le % disque dispo diminuait.
Maintenant que j’ai réussi, je me retrouve avec:
Espace disque libre: 31%
Un fichier de backup qui est passé de 230Mo à 72Mo.
Encore un grand merci à vous 2 pour votre aide.
1 « J'aime »