Problème de migration 3.4.3 -> 3.5.2

Bonjour,

j'essaie de restaurer une sauvegarde d'une instance de GRR d'un serveur vers un autre.

Vois les infos de version:
ancien:

Numéro de version GRR fichier : 3.4.3 
Numéro de version GRR BDD : 3.4.3
Préfixe : grr
---
Version PHP : 7.4.33
Base de donnée : mysql 5.7.44-48-log

nouveau:

Numéro de version GRR fichier : 3.5.2a 
Numéro de version GRR BDD : 3.5.2
Préfixe : grr
---
Version PHP : 8.0.30
Base de donnée : mysql 10.5.27-MariaDB

J'ai réalisé la sauvegarde de l'ancien et généré un fichier sql que je récupère sur le nouveau. 
Lorsque je passe par l'outil intégré de restauration et que je sélectionne mon fichier, je suis redirigé vers /admin/admin_open_mysql.php et la page indique:

xxxxxxxxxxxx.fr ne peut pas traiter cette demande pour le moment.
HTTP ERROR 500 

Je ne trouve pas de log.

Si j'essaie de réimporter directement le fichier dans une base vide, l'import se passe sans erreur au niveau de la base de données. Par contre quand je me connecte j'ai un message qui indique:
La connexion au serveur mysql est établie mais certaines tables sont absentes de la base grr
Lorsque je clique sur "Mettre à jour la base mysql", je suis redirigé vers une fenêtre d'authentification, mais je ne peux pas me connecter, "Identifiant ou mot de passe incorrect" alors que j'ai essayé toutes les combinaisons connues.

Autre information, il y a peut-être un soucis d'encodage ou de moteur de stockage des données:

Issu du dump de la nouvelle base post installation: ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci;
dump de l'ancienne: ENGINE=MyISAM AUTO_INCREMENT=32 DEFAULT CHARSET=latin1;

Auriez-vous une piste ?
Merci.
 

Bonjour,
désolé pour cette réponse tardive.
Il y a eu quelques corrections sur le script de mise à jour, il faudrait reprendre la procédure initiale (installation de la version 3.5.2, puis restauration de la base ancienne) avec les dernières versions des scripts, récupérée à partir de cette page : github.com/JeromeDevome/GRR/tree/GRR-3.5.2
Si cela pose encore problème, on essaiera de voir ce qui cloche.
Cordialement,
YN

Bonjour,

merci pour la réponse.
finalement j'ai recommencé avec une version plus récente ( github.com/JeromeDevome/GRR/tree/GRR-4.3.X ), mais je rencontre le même problème à la restauration de la bdd.

HTTP ERROR 500
 

Bonjour,
si vous regardez l'historique des dépôts sur github, vous constaterez que la version 3.5.2 est autant suivie que la version 4.3.
Ces deux branches ne suivent pas la même philosophie : la branche 3.5 est légère (moins de 20 MO de scripts) alors que la branche 4 utilise Symfony et d'autres outils externes.
Pour en revenir à votre problème de restauration de la base de données 3.4.3 dans 3.5.2 ou 4.3.9, il faudrait tenter la manip' avec les scripts les plus récents de la branche 3.5.2 pour voir si les derniers correctifs apportés sont efficaces
Si cela ne fonctionne toujours pas, pouvez-vous accéder aux journaux de MySQL (ou MariaDB)? Les échecs précédemment rencontrés étaient dus à une erreur MySQL non rattrapée...
Cordialement,
YN

Bonjour,

je suis donc reparti avec la version 3.5.2 récupérée sur github.com/JeromeDevome/GRR/tree/GRR-3.5.2
mais je rencontre toujours l'erreur lors de la restauration de la sauvegarde.

Merci pour votre aide.

Toujours erreur http 500 ?
Vous n'avez pas dit si vous avez accès aux journaux de Apache, php et MySQL.
Si c'est le cas, que disent-ils ?

Oui, toujours la même erreur,

log apache:
[26/May/2025:10:42:49 +0200] "POST /admin/admin_open_mysql.php HTTP/1.1" 500 -

Le log de mariadb est vide.

Je n'ai pas pu reproduire cette erreur.
Cependant, une restauration d'une base 3.4.0 m'a produit une erreur Warning, que j'ai corrigée par ce commit : github.com/JeromeDevome/GRR/commit/c839e...1869de6cbe4be27cf7df
Ensuite j'ai testé la restauration depuis une base 3.4.0 puis 3.4.3 et les deux sont passées sans erreur.
Une autre piste ? Quelle est la taille de votre fichier de sauvegarde ?

Le fichier n'est pas lourd, 36Ko pour 15358 lignes.

J'ai fait une sauvegarde de la base vide post installation et la restauration de celle-ci fonctionne.
J'ai ensuite modifié le fichier SQL en incorporant manuellement la partie données de l'ancienne sauvegardes dans la nouvelle.
je tombe toujours sur une erreur 500 à l'import.

En essayant de créer une base vide et d'importer le fichier sql depuis la commande mysql, j'ai une erreur :

INSERT INTO grr_area  values ('4', 'Nom salle', 'r', '0', '', '8', '19', '7200', '900', '0', '1', '1', 'n', 'y', 'nyyyyyn', '-1', '900', '3')

---

ERROR 1136 (21S01) at line 42: Column count doesn't match value count at row 1

En comparant les deux fichier sql, la table grr_area ne semble pas avoir la même structure, j'ai ces lignes en plus.
  `user_right` int(11) DEFAULT NULL,
  `access_file` int(1) DEFAULT NULL,
  `upload_file` int(11) DEFAULT NULL,

 

Bonjour,
merci pour votre retour.
La séquence de commandes SQL à exécuter est : lignes issues de la sauvegarde en version 3.4.3.
Ainsi les données correspondent au format de la table grr_area.
Dans la phase de mise à jour, les champs manquants sont ajoutés et le format des données textuelles passe de latin1 à utf8mb4.
Puisqu'apparemment c'est la phase de restauration qui pose problème, il faudrait peut-être tenter une restauration table par table pour trouver l'erreur.
Bon courage !
Cordialement,
YN