Vous n'êtes pas identifié(e).
Pages : 1
Alors dans l'exemple que je cite, je suis sur un vieux PC (Dell X300), sur un autre, c'est sda2 à la place de sda3
J'ai ceci sur le disque de backup :
J'ai commencé à faire une image avec clonezilla 386 (pour Jessie) : image db1
J'ai ensuite une image avec clonezilla 386 (pour Stretch) : image st2
J'ai ensuite une image avec clonezilla 686 PAE (pour XUbuntu) : image xu2
L'image st1 a existé, car j'avais pour cette image désinstallé Firefox, mais cela a été remis pour st2 (car cela vient de la Ram à upgrader : 640 MB de Ram est insuffisant pour Firefox à partir de Stretch)
L'image xu1 a existé également mais elle ne contient rien de valable du fait que clonezilla 386 avait été utilisé, d'où l'image xu2 par la suite.
Le reste est clair, je mets toujours les logiciels à utiliser sur le disque de Backup.
Depuis que Clonezilla s'est planté, j'ai ceci pour son utilisation par la suite :
Vous voyez de suite pourquoi je tiens au Fat32 car ça n'a pas été vérolé alors que "Backup" a été vérolé.
L'instruction donnée plus haut corrige le problème et je retrouve avec cela mon "Backup"
La cause est dans le cas présent de vouloir faire une image avec la version de Clonezilla 386 pour une partition qui contient Xubuntu Bionic et cela donne ceci comme message à l'écran, ce qui explique l'usage par la suite de clonezilla 686 PAE. Ce CD fait planter le processus à la fin et donne l'erreur donnée en image avant :
Ce cas-ci est simple, car il n'y a qu'un seul disque de Backup, mais sur ma tour par exemple, j'en ai jusque trois et là il faut alors se rappeler qui est le "dirty", je m'y retrouve un peu avec les tailles. Même en d'autres circonstances, on peut se tromper à l'utilisation de clonezilla et avoir cette erreur.
J'ai donc avec cette instruction le moyen de corriger, Windows ne corrigera pas par exemple automatiquement un disque dur externe.
Le problème est devenu plus péoccupant qu'avant de par les nouvelles versions de Linux. Pour XP et même Win 7 ou Win 10, la distinction PAE et non PAE n'est pas nécessaire et bien souvent les versions 386 ou 486 de Clonezilla sont amplement suffisantes et elles sont plus rapides également. Le problème survient avec Linux et particulièrement avec un dualboot. L'utilisation de la version 686 augmente assez bien la durée de l'opération et je suis toujours content du fait que je suis coincé avec Linux car je peux sous Windows réutiliser la version 386 ou 486 de clonezilla comme avant. Linux accepte ce genre d'erreur, le clonage reste possible, mais cela laisse des traces visibles (qui sont gênantes à l'utilisateur pour Clonezilla. La meilleure des solution est je pense que clonezilla détecte le défaut en corrigeant de suite avant de pouvoir le voir et donc de s'en rendre compte. Clonezilla le fait peut-être en fin de procédure de clonage, mais comme il ne va pas jusquà la fin à cause d'un "freeze", c'est pas corrigé pour sûr. Ce n'est non plus pas corrigé en début de procédure, puisque l'erreur devient visuelle. Ou alors c'est corrigé pour du NTFS et pas du FAT32.
S'il faut prendre la dernière version, c'est laquelle car j'en ai déjà vu des tonnes. Ensuite, la dernière version au moment de l'écriture du fichier Iso sur le disque de Backup risque de changer encore bien souvent.
Linux pourrait aussi vérifier l'intégrité des disques avant de démarrer en se limitant au paramètre adéquat car l'instruction complète prend plus d'une minute d'exécution.
La dernière version est maintenant 686 PAE 2.6.2.15 et remplace une autre "dernière version 686 PAE 2.5..... et cela va mieux avec cette dernière version ci.
C'est bien plus lent à la création d'une image (2x environ) et nettement plus compliqué à utiliser que la version 386. La restauration des images commence assez lentement mais cela s'accélère par la suite et fait que la durée d'une restauration est quasi inchangée.
Jusque quand sera t'elle la dernière version stable ?
Je mets maintenant l'instruction à appliquer sur le disque de backup, ce qui réduit les problèmes possibles par la suite.
S'il y a des amateurs pour en faire un sujet utile ou compléter un utilitaire existant, c'est évidemment autorisé de prendre des infos ici car en fin de compte, je parle d'un problème qui revient souvent et sur différents PC.
Dernière modification par Guy19550 (07-09-2019 02:02:16)
Hors ligne
C'est plus rapide à faire, avec les paramètres utilisés, la correction se fait, mais c'est à faire manuellement en répondant à des questions. C'est donc clair que dans le cas AMD 64, en le faisant automatiquement, c'est la solution de ne rien faire qui est choisie, et que manuellement, on peut choisir la bonne solution à effectuer. La première instruction ne sait pas faire ce choix de manière automatique car ne sait pas quelle est la bonne chose à faire. C'est ainsi que je vois les choses.
Pourquoi ne sait-on pas faire en 64 bits, ce que l'on sait le faire en 32 bits, that's the question.
Dernière modification par Guy19550 (08-09-2019 05:54:05)
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Hors ligne
Dernière modification par Debian Alain (08-09-2019 15:57:07)
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Dernière modification par Guy19550 (09-09-2019 01:06:30)
Hors ligne
Dernière modification par Guy19550 (09-09-2019 02:20:07)
Hors ligne
Dernière modification par Guy19550 (09-09-2019 02:22:57)
Hors ligne
Hors ligne
Hors ligne
Pages : 1