J'ai installé une Asus K8N (chipset NForce 3) avec Windows XP et différents logiciels.
J'ai mis un coup de sysprep puis fait une image avec Ghost 7.5
J'ai redescendu l'image sur une machine à base de P4P800S-X (chipset Intel).
Le démarrage de Windows XP n'a posé aucun soucis.
Donc jusque là tout va bien.
J'ai configuré la nouvelle machine (carte graphique), relancé sysprep et refait une image.
J'ai redéployé l'image sur la première config et là, j'ai eu un BSOD au démarrage.
Ce ne serait pas grave si je n'avais pas écrasé la première image par la seconde.
Ainsi, il ne m'est plus possible de travailler sur la première config.
J'ai essayé de modifier mon sysprep.inf en ajoutant le paramètre BuildMassStorage = Yes, de remplacer mon controlleur IDE Intel par le standard double canal PCI, rien n'y a fait.
J'ai essayé également d'utiliser OemPnPDriversPath en spécifiant le chemin vers les fichiers .inf et .cat du chipset Nforce, même constat d'échec.
Ce n'est pas un problème de multi/mono processeur puisque j'ai d'un côté un Sempron et de l'autre un Celeron.
Par contre, la couche HAL est peut-être la clé car si ma config Intel est ACPI, je ne sais pas si l'AMD l'est aussi.
Si l'un d'entres vous a une solution pour pouvoir dupliquer ma seconde config (Intel) sur ma première config (AMD), je suis toutes ouïes.
à la base les ghost sont fait pour la config à partir de laquelle l'image a été crée, c'est donc normal si ca ne fonctionne pas en l'installant sur un pc avec une configuration différente
le fait que cela ait marché sur ton autre configuration est un pur coup de chance
ghost est surtout utilisé pour installer windows ou tout autre os sur un parc de machines de configurations identiques
Oui mais non c'est plus subtil que ça.
Le problème se situe au niveau de l'ACPI hors j'ai vérifié, les deux configs le sont.
Normalement, en mettant un controleur standard ça doit passer.
XP n'est pas 98 : XP gère les composants installés avec leurs identifiants uniques et des pilotes spécifiques.. 98 ne faisait rien de ça et se contentait de faire un scan PnP à chaque démarrage, ce qui avait le don, parfois, de ré-installer des pilotes génériques en lieu et place de pilotes de constructeurs pourtant déjà installés..
XP est plus précis, d'autant qu'il prend en compte les ID de certains composants (notamment la mobo, donc son chipset) pour générer sa clé d'activation..
La seule chose qui fonctionne est l'usage en usine pour la vente aux particuliers ou en entreprise pour un parc de bécanes de licences spécifiques autorisant la génération d'une image "maison" (systèmes + applis sélectionnées) et le déploiement de celle-ci sur des machines identiques..
Sinon, c'est trop facile : tu installes un XP légal sur une bécane, tu effectues l'activation et tu génères une image système que tu vas ensuite utiliser pour répandre cet XP activé sur les bécanes de tes potes ..
Autrement, toutes les configs actuelles sont ACPI et avec le réglage par défaut du bios sur "Enabled".. Et ce depuis le pII (ACPI seulement partiel avec les premiers pII).. Ma frangine a même encore son vieux K6-II dont la mobo est aussi ACPI (partiel, comme les premiers pII).. L'implémentation complète de l'ACPI a été réalisée avec les premiers pIII et Athlons.. Et certaines cartes mères à l'ancien format AT pouvaient fonctionner avec des alims ATX, seules équipées de la gestion de l'alimentation et aussi capables de fournir le +3.3v nécessaire par exemple à l'AGP 1.0 de l'époque et à la SDRAM (exemple : l'Asus P5A-B, Socket "Super7" : pMMX, K6-II, K6-III)..
Message édité par Johan_et_Pirlouit le 25-06-2006 à 00:39:29
Pour le reste, t'es HS. Il n'est pas question d'activation, j'ai une clé VLK.
De plus il est tout a fait possible de déployer sur des configs différentes. Sysprep le gère avec des options comme OemPnPDriversPath et BuildMassStorage.
D'ailleurs ma première restauration s'est bien déroulée. C'est la restauration dans l'autre sens qui ne fonctionne pas.