You are not logged in.
Bonjour
Je me retrouve avec un vieux GLPI 0.71.5 / OCS-ng 1.0.1 (Ubuntu 8.04) que je veux / dois passer à 0.80 avec FusionInventory for GLPi 2.4 sur un Debian squeeze.
Je me suis procuré d'une copie de la base de donné en prod pour tester la mise à jour avec les plugins pour les version correspondantes (nous avons treeview et certificates). Donc la mise à jour sur la dernière version de la branche 0.71 (0.71.6) puis 0.72.4 se passe sans problème - ca semble marcher après.
Quand je veux passer à 0.78.4 je reçois une erreur - mais je peux encore continuer et me reconnecter à GLPI. Toute mise à jour se passe bien mais les erreurs apparaissent dans la section au passage sur 0.78, pas 0.78.x:
You can delete backup tables if you have no need of them
Error: glpi_computerdisks.FK_computers doesn't exist
Error: glpi_computerdisks.FK_filesystems doesn't exist
Pire: Quand je veux passer à 0.80(.2) l'assistant bloque dans la mise à jour sur:
0.80 populate glpi_crontasks for slaticket Fehler während der Aktualisierung der DatenbankDuplicate entry 'SlaLevel_Ticket-slaticket for key 'unicity'
(C'est un GLPI allemand, mais ca dit simplement que il y a eu une erreur pendant la mise à jour de la base de données.)
Last edited by kofi (2011-09-20 21:14:56)
Offline
Il y avait un petit bug dans la migration de la 0.80.3 (procédure non réentrante), corrigé en 0.80.3.
Dans tout les cas, je pense que la procédure n'a pas aboutit car top longue.
=> repartir de la sauvegarde et gonfler les paramètres php (mas_execution_tim + memory_limit) et relancer la procédure
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Salut remi
J'ai gonflé les valeurs
memory_limit 128 -> 512
max_execution_time 30 -> 300
Malheureeusement sans succes. Il y a les mêmes erreurs au passage à la 0.78 et à 0.80 c'est fini.
Question peut-etre en relation avec le problème: Je n'ai pas déactivé les plugins (certificates et treeview) - je me rappelle que les certificats rentré dans la base étaient perdu que je déactivais les plugin. (j'ai bien toujour remplacé la version des plugins avec la version compatible de chaque version GLPI)
Last edited by kofi (2011-09-21 07:56:20)
Offline
Normalement, si les plugins ne sont pas désactivés, la migration le fait.
Par contre, vos valeurs php sont insuffisantes car entre la 0.72 et la 0.78 il y a une grosse migration du schéma de la base.
Avant la migration, je préconise de mettre les valeurs à 0 pour le max_execution_time et à -1 pour le memory_limit
et remettre vos valeurs une fois la migration effectuée
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour
Augmenté la mémoire de la VM de 1G à 4G
php.ini: max_execution_time 0
php.ini: memory_limit = 3500M
Aucun changement :-/
Pendant le passage la mémoire utilisé par mysqld et apache (dans top) ne dépassent pas les 512Mo chacun.
Il se pourrais que la base en 0.71 aurait un défaut?
Update: J'a mal a croir que c'est une question de mémoire vu que j'ai eu aucune différence avec 4x plus de mémoire (à peine 200 ordis dans la base).
Vu que nous avons devant nous une migration OCS->Fusion et besoin de quelques modifs locales j'ai reçu l'OK d'engager un contribueur GLPI pour nous dépanner entre autre avec ce problème. - Mais je vais ajouter les résultats dès possible.
Merci déjà pour votre soutien.
Last edited by kofi (2011-09-21 21:09:58)
Offline
Vous pouvez assez de migrer de 0.71 à 0.72.4 et vérifier que vous avez bien la table glpi_computerdisks (elle est apparue en 0.72)
Ensuite, vérifier dans cette table que vous avez bien les champs indiqués manquants.
Si tout est OK et que la 0.72.4 fonctionne, faites la migration de 0.72.4 à 0.80
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour,
Je suis confronté au même problème, est ce que le votre a été résolu ?
Merci d'avance ...
Offline
The business model is very similar to that of a more well-known brand, one that rhymes with 'oogle'. They connect Advertisers (people with stuff to promote) with Publishers (website owners who want to monetize their site). By acting as the middle-man between these two groups on a large-enough scale, they are ablebanners broker to rent space on publishers' websites in a cost effective way, and make a nice profit from the resulting advertising trade. Google do pretty much the same thing.
Offline