PC-Image auf anderen Rechner übertragen - Treiber offline unterjubeln?

[Sabbelbacke]

Hey,

ich hab ja schon so manchen Rechner "umgezogen", aber diesmal ist es irgendwie noch zickiger als sonst... Und da ich jüngst erst einen alten Rechenr virtualisiert hatte, kam mir folgende Idee:

Diese ganzen Virtualisierungsconverter wie "vmware converter" nehmen z.B. ein Acronis Image, lutschen das einmal durch und tauschen dabei alle relevanten Treiber und Innereien so aus, dass hinterher aus dem Image eine funktionierende Vm wird....

Gibt es nicht ein Tool, mit dem man das gleiche machen könnet, um - wie in meinem Fall - eine alte AMD-Plattforms Install auf IDE Basis auf Intel Core SATA Basis umzumüpfen (zumindest mal soweit, dass man wenihgstens im abgesicherten Modus irgendwo hin kommt...)

[BergH]

tach auch !

Image ziehen.
Rechner in den abgesicherten fahren.
ALLE Treiber möglichst deinstallieren.
Image ziehen.
Image auf neuen Rechner aufspielen.
Alle treiber auf die neue Partition spielen.
Im abgesicherten Modus satrten und neue Treiber installieren.
Beten.
Hoffen, dass er anspringt.

Kasnn gut gehen , muß aber nicht.
NeuInstall ist in jedme Falle saueberer.

Tools ?

So gut und so schlecht wie der Sex den die Programmierer am Tag vor der Veröffentlichung hatten. ;)
(O,K, Programmierer haben ja gar keinen .....)

BTW: Deine Katze mach mich rappelig :Keule:

[sasmi]

Gute Hilfe leistet auch der MergeIDE Trick, wie er in der c't (http://www.heise.de/ct/artikel/Reanimation-289830.html) beschrieben ist.

So habe ich mit Hilfe des VMware Converters eine XP Installation unter VirtualBox virtualisiert.
Es sollte Windows 7 installiert werden, aber man sollte auch noch auf die Windows XP Installation zu greifen können.
So läuft jetzt Windows 7 64 Bit mit VirtualBox und als virtuelle Maschine das "alte" Windows XP.
Man kann den Festplattenkontroller der VM später auf SATA umstellen.

[Berfet]

tach auch !

Image ziehen.
Rechner in den abgesicherten fahren.
ALLE Treiber möglichst deinstallieren.
Image ziehen.
Image auf neuen Rechner aufspielen.
Alle treiber auf die neue Partition spielen.
Im abgesicherten Modus satrten und neue Treiber installieren.
Beten.
Hoffen, dass er anspringt.

Kasnn gut gehen , muß aber nicht.
NeuInstall ist in jedme Falle saueberer.

Tools ?

So gut und so schlecht wie der Sex den die Programmierer am Tag vor der Veröffentlichung hatten. ;)
(O,K, Programmierer haben ja gar keinen .....)

BTW: Deine Katze mach mich rappelig :Keule:

Mit der Methode hab ich letztens auch einen Rechner mit XP zum laufen gebracht.

[Sabbelbacke]

Danke Euch allen. Das plöthe ist, dass der alte Rechner gestorben ist, ich also nur noch Zugriff auf das Acronis Image (oder die physikalisch noch vorhandene Festplatte, die netterweise als IDE am neuen Rechner nicht mehr dranstöpselbar ist, weil SATA exklusiv dort...)
Na dann fummel ich mal weiter. Die virtuelle Maschine hatte ich auch schon geplant und den c't Artikel im Hinterkopf, ich hatte nur gehofft, es gäbe was "elegantes", wo man einfach dem Image ein paar neue Treiber unterjubeln könnte :)

[Sabbelbacke]

haha, das lange Suchen im Netz..... Ich hab ein paar der obigen Dinge probiert, aber irgendwie hats dann doch irgendwo gehangen... Sogar ein Update von WIN mit einer geslipstreamten XP CD habe ich mal durchgespielt... Jetzt gerade habe ich gefunden:

FIX_hdc

Ein Plugin für BARTsPE, das mir offline den COntroller tut tauschen tun... Na da wollen wir mal..

[Sabbelbacke]

Update:

FIX-HDC brauchte ich doch nicht... während des Downloads und der Erstellung einer BARTsPE war ich dem total simplen Ding hier gefolgt:

http://support.microsoft.com/default.aspx?scid=kb;en-us;824125

Dass sich methodisch ja an einiges anlehnt, was oben geschrieben wurde, nur überraschenderweise noch simpler war...

In Summe also geschehen:

- Acronis Backup eines nicht mehr existierenden ATHLON XP mit VIA XYZ Chipsatz soll auf "aktuellen" Intel 865 Chipsatz Celeron D irgendwas mit AHCI SATA Platte
- Das Image mittels vmware Converter in eine virtuelle Maschine gewandelt.
- Dort erst mal alles, was "VIA" und "AMD" war im Gerätemanager rausgeworfen - zur Sicherheit
- Dann mittels nlite eine WInXP Installation gestrickt, die die Treiber des zukünftigen Systems schon enthielt.
- mit dieser Install-CD dann unter der virtuellen Maschine im hochgefahrenen WIndows ein Update gestartet (was sich beim booten von der CD direkt nicht einleiten lässt)...
- Inmitten dieses Updateporzesses (in der virtuellen Maschine auf einem i3/SSD ging das in sekunden..) bootet die virtuelle Maschine einmal...
- Genau diesen Bootprozess nicht neu laufen lassen sondern nach dem runetrfahren "aus machen".. Dann die PLatte wieder auf den neuen Rechner schieben, sprich: in der virt. Maschine mittels acronis trueimage die virtuelle Platte als Backup ins Netz, von da wieder auf dem realen, neuen Rechner auf die SATA Platte.
- Realen Rechner jetzt starten.. Das virtuell angestossene Backup setzt sich wundersamerweise einfach fort - AHCI Treiber müssten dank Slipstream ja auf der vorhin erstellten Windowx-XP-INstall CD drauf sein, zur SIcherheit aber noch auf Diskette mittels F6 während des Installs untergeschoeben...


Von hier an wars dann einfach.. Das Update jubelt dem alten XP einfach die Innereien neu unter, so dass man beim "alten" Windows mit neuem Systemtreibern rauskommt. Zur Sicherheit noch mal manuell alle relevanten Treiber und Hotfixes, Service Packs usw.. drüber.. Aufgeräumt.. Voilá.

IDE - gegen AHCI SATA getauscht
Uralt HAL "STandard PC" gegen ACPI Mutlicore HAL getauscht
Chipsatztreiber erneuert...


Jetzt räum ich die Kiste noch ein wenig auf. Vielen Dank für die ganzen Hinweise oben, die haben mir gute Ideen geliefert.

PS: FIX_HDC hab ich jetzt gar icht ausprobiert, owbohl das lustigerweise genau das können soll, was ich im Ursprungspost wissen wollte... Nur war meine letzte Aktion schnelelr fertig als FIX-HDC einsatzbereit....

[Sabbelbacke]

Nachtrag:

BergHs Methode wollte übrigens deswegen nicht, weil der alte Rechner einen komplett anderen Chipsatz hatte als die neue Kiste, sprich nicht nur IDE/SATA war untershciedlich, auch der ganze Rest.. Man kam also selbst mit "kastriertem Windows" nie über den kurzen Bootpromt, sofort blieb alles stehen.. Diese Methode klappt gut, wenn z.B. der Chipsatz vom gleichen Hersteller ist.

MergeIDE scheiterte daran, dass weder der neue noch der alte Rechner einsatzfähig waren und die PCI-IDs so erst mal nicht ersichtlich waren, bzw,. falsch.. Bei FSC war unter der Modellnummer ein anderer Chipsatz angegeben, als tatsächlich verbaut, wie sich rausstellte, machte der kleine Appendix im Namen des Gerätes alles aus... Selbst nachdem ich das aber hatte, reichte es nicht aus, denn die HAL an sich weigerte sich auf dem neuen Rechner auch (ntldr ging anscheinend noch, danach war essig).