12
Migration von m.2 SATA-SSD nach m.2 NVMe-SSD schlägt fehl
Hallo zusammen,
ich versuche nun schon seit mehreren Stunden ein Windows 10 von einer M.2 SATA-SSD auf eine M.2 NVMe-SSD umzuziehen.
Der PC hat einen M.2-Slot und so habe ich mit einem USB-Stick ein aktuelles Acronis Boot Medium gestartet und zunächst die M.2 SATA-SSD auf eine 2,5 Zoll SATA SSD geklont.
Anschließend die M.2 SATA SSD entfernt und dann konnte ich von der 2,5 Zoll SATA SSD auch problemlos booten.
Nun habe ich die M.2 NVMe-SSD eingesetzt, wieder vom USB-Stick das Acronis Boot Medium gestartet und damit dann die 2,5 Zoll SATA SSD auf die M.2 NVMe-SSD geklont.
Anschließend die 2,5 Zoll SATA SSD entfernt und nun wollte ich von der M.2 NVMe-SSD booten - aber das schlägt leider fehl.
Im UEFI wird der Speicher korrekt als NVMe-Speicher erkannt, also das Board scheint NVMe zu können.
Beim Booten kommen dann so schöne Fehlermeldungen wie: "Inaccessible Boot Device" oder auch "c:\windows\system32\winload.efi" fehlt oder nicht in Ordnung.
Ich hab nun schon alle möglichen Webseiten abgegrast und alles mögliche versucht:
1)
Die EFI-Partition wird korrekt angezeigt (in Minitool Partition Wizard): FAT32, GPT, Aktiv & System, 100MB.
Hab sie auch mal entfernt und neu angelegt.
2)
Ich habe verschiedene Varianten von bcdboot ausprobiert:
-bcdboot c:\windows
-bcdboot c:\windows /s t: /f UEFI
usw.
Dabei war das c:\windows mal das windows von der NVMe-SSD, als auch das windows von der 2,5 Zoll SATA-SSD.
3)
Auch habe ich versucht die winload.efi mal händisch von der SATA-SSD auf die NVMe-SSD zu kopieren - hat auch nix gebracht.
4)
Starte ich Windows von der 2,5 Zoll SATA-SSD wird im Gerätemanager ein NVMe-Treiber angezeigt - an einem fehlenden Treiber sollte es also auch nicht liegen (das ist glaub ich eh nur unter Windows 7 ein Problem gewesen).
5)
Vor dem Klonen habe ich das Dateisystem mit chkdsk /f /r in Ordnung gebracht.
6)
Die Platten sind alle GPT und im UEFI ist Secure Boot deaktiviert.
So langsam bin ich mit meinem Latein am Ende. Bei Youtube gibt es für genau dieses Szenario (SATA-SSD auf NVMe-SSD) durchaus Tutorials, die einfach nur die Platten klonen, ohne treibertechnisch oder sonstwelche Extras zu veranstalten - und da geht es. Irgendwie muss es also möglich sein.
Das Klonen habe ich mit MiniTool Partition Wizard 12.6 sowie mit dem Acronis Boot Medium probiert.
Kann mir jemand vielleicht den entscheidenden Wink mit dem Zaunpfahl geben, woran es liegen könnte und wie es zu lösen ist?
Vielen Dank vorab!
Gruß
Colt
ich versuche nun schon seit mehreren Stunden ein Windows 10 von einer M.2 SATA-SSD auf eine M.2 NVMe-SSD umzuziehen.
Der PC hat einen M.2-Slot und so habe ich mit einem USB-Stick ein aktuelles Acronis Boot Medium gestartet und zunächst die M.2 SATA-SSD auf eine 2,5 Zoll SATA SSD geklont.
Anschließend die M.2 SATA SSD entfernt und dann konnte ich von der 2,5 Zoll SATA SSD auch problemlos booten.
Nun habe ich die M.2 NVMe-SSD eingesetzt, wieder vom USB-Stick das Acronis Boot Medium gestartet und damit dann die 2,5 Zoll SATA SSD auf die M.2 NVMe-SSD geklont.
Anschließend die 2,5 Zoll SATA SSD entfernt und nun wollte ich von der M.2 NVMe-SSD booten - aber das schlägt leider fehl.
Im UEFI wird der Speicher korrekt als NVMe-Speicher erkannt, also das Board scheint NVMe zu können.
Beim Booten kommen dann so schöne Fehlermeldungen wie: "Inaccessible Boot Device" oder auch "c:\windows\system32\winload.efi" fehlt oder nicht in Ordnung.
Ich hab nun schon alle möglichen Webseiten abgegrast und alles mögliche versucht:
1)
Die EFI-Partition wird korrekt angezeigt (in Minitool Partition Wizard): FAT32, GPT, Aktiv & System, 100MB.
Hab sie auch mal entfernt und neu angelegt.
2)
Ich habe verschiedene Varianten von bcdboot ausprobiert:
-bcdboot c:\windows
-bcdboot c:\windows /s t: /f UEFI
usw.
Dabei war das c:\windows mal das windows von der NVMe-SSD, als auch das windows von der 2,5 Zoll SATA-SSD.
3)
Auch habe ich versucht die winload.efi mal händisch von der SATA-SSD auf die NVMe-SSD zu kopieren - hat auch nix gebracht.
4)
Starte ich Windows von der 2,5 Zoll SATA-SSD wird im Gerätemanager ein NVMe-Treiber angezeigt - an einem fehlenden Treiber sollte es also auch nicht liegen (das ist glaub ich eh nur unter Windows 7 ein Problem gewesen).
5)
Vor dem Klonen habe ich das Dateisystem mit chkdsk /f /r in Ordnung gebracht.
6)
Die Platten sind alle GPT und im UEFI ist Secure Boot deaktiviert.
So langsam bin ich mit meinem Latein am Ende. Bei Youtube gibt es für genau dieses Szenario (SATA-SSD auf NVMe-SSD) durchaus Tutorials, die einfach nur die Platten klonen, ohne treibertechnisch oder sonstwelche Extras zu veranstalten - und da geht es. Irgendwie muss es also möglich sein.
Das Klonen habe ich mit MiniTool Partition Wizard 12.6 sowie mit dem Acronis Boot Medium probiert.
Kann mir jemand vielleicht den entscheidenden Wink mit dem Zaunpfahl geben, woran es liegen könnte und wie es zu lösen ist?
Vielen Dank vorab!
Gruß
Colt
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5940083166
Url: https://administrator.de/contentid/5940083166
Ausgedruckt am: 22.11.2024 um 06:11 Uhr
12 Kommentare
Neuester Kommentar
Du könntest noch ein Backup mit Veeam ziehen, die Platte tauschen und auf die nvme Recovern.
So konnte ich damals mein Clone Problem mit der nvme lösen.
So konnte ich damals mein Clone Problem mit der nvme lösen.
Moin @coltseavers,
das hört sich für mich so an, als ob lediglich der Bootmanager am A.... ist, respektive nicht zu der Disk ID der NVME passt.
Schau dir mal die folgende Reparaturanleitung an ...
https://www.heise.de/tipps-tricks/Windows-10-Bootmanager-reparieren-so-g ...
Gruss Alex
Kann mir jemand vielleicht den entscheidenden Wink mit dem Zaunpfahl geben, woran es liegen könnte und wie es zu lösen ist?
das hört sich für mich so an, als ob lediglich der Bootmanager am A.... ist, respektive nicht zu der Disk ID der NVME passt.
Schau dir mal die folgende Reparaturanleitung an ...
https://www.heise.de/tipps-tricks/Windows-10-Bootmanager-reparieren-so-g ...
Gruss Alex
Hi,
ich hatte den gleichen Fehler gestern auch und konnte ihn auf die Schnelle nicht beheben.
Schau mal hier:
https://thinkpad-forum.de/threads/gel%C3%B6st-x260-umr%C3%BCsten-von-sat ... (Entfernen eines Reigistry Eintrages).
Nicht geprüft.
Gruß
CH
ich hatte den gleichen Fehler gestern auch und konnte ihn auf die Schnelle nicht beheben.
Schau mal hier:
https://thinkpad-forum.de/threads/gel%C3%B6st-x260-umr%C3%BCsten-von-sat ... (Entfernen eines Reigistry Eintrages).
Nicht geprüft.
Gruß
CH
Moin,
Da müssen vremutlich nur die Bootdateien auf der EFI-Partition neu geschrieben werden und dem BIOS gesagt werden, welcher Boot-manager zu laden ist.
Also einfach mit einem WinPE (InstallationsMedium oder Notfallsysten, wie z.B. ct-Notfalwindows, BartPE o.ä.) booten und im der Kommandozeile mit bcdboot die Bootdateien und den UEFI-Booteintrage (/f UEFI) neu schreiben lassen. Danach sollte das Booten wieder funkltionieren.
lks
Da müssen vremutlich nur die Bootdateien auf der EFI-Partition neu geschrieben werden und dem BIOS gesagt werden, welcher Boot-manager zu laden ist.
Also einfach mit einem WinPE (InstallationsMedium oder Notfallsysten, wie z.B. ct-Notfalwindows, BartPE o.ä.) booten und im der Kommandozeile mit bcdboot die Bootdateien und den UEFI-Booteintrage (/f UEFI) neu schreiben lassen. Danach sollte das Booten wieder funkltionieren.
lks
Zitat von @Looser27:
Du könntest noch ein Backup mit Veeam ziehen, die Platte tauschen und auf die nvme Recovern.
So konnte ich damals mein Clone Problem mit der nvme lösen.
Du könntest noch ein Backup mit Veeam ziehen, die Platte tauschen und auf die nvme Recovern.
So konnte ich damals mein Clone Problem mit der nvme lösen.
Ahoi,
danke für den Tip!
Welche Version hast Du denn benutzt: Den Veeam Agent for Windows Free, oder Backup and Recovery?
(sollte ja theoretisch beides gehen, aber theoretisch sollte es ja auch kein Problem sein die Platten zu clonen... )
Gruß
Colt
Ich habe das mit der Free Version gemacht.
Ging reibungslos.
Ging reibungslos.
Danke Dir - aber das Problem bleibt leider identisch: -> beim 1. Boot kommt: inaccessible Boot device.
Zitat von @Lochkartenstanzer:
Also einfach mit einem WinPE (InstallationsMedium oder Notfallsysten, wie z.B. ct-Notfalwindows, BartPE o.ä.) booten und im der Kommandozeile mit bcdboot die Bootdateien und den UEFI-Booteintrage (/f UEFI) neu schreiben lassen. Danach sollte das Booten wieder funkltionieren.
wie ich schon unter Punkt 2) meines Eröffnungsthreads geschrieben habe, gehörte genau das zu den ersten Dingen, die ich versucht hatte, undzwar in allen möglichen Varianten.
Kannst Du einen Hardware Defekt ausschließen?
Ich denke schon - der Rechner läuft ja auch weiterhin unter der alten M.2 SATA - sie ist halt nur zu klein geworden und soll deshalb ersetzt werden.
Auch auf der neuen NVMe-SSD lässt sich ein neues Windows installieren -> vermutlich wird es nun auch auf eine Neuinstallatoin hinauslaufen. Würde zwar gern weiter forschen, woran es liegt, weil ichs echt gern wissen möchte, aber die Aufgabe ist schon jetzt zeitlich gesehen eine Katasrophe...
Ich hatte vor dem Clon-/Backupvorgang ein chkdsk /f /r gemacht. Vielleicht ist es in diesem Fall zusätzlich erforderlich auch noch ein sfc /scannow zu machen.
Das wird mir nun zeitlich aber alles zu aufwändig. sfc /scannow -> neues Backup -> neuer Restore...
Hallo nochmal!
Unglaublich, aber wahr: es funktioniert!
Komischerweise lässt sich nicht präzise feststellen, woran es lag.
Was ich zuletzt gemacht hab:
Ich habe mit dem kostenlosen Veeam Backup Agent für Windows (Free) ein Backup der Systempartitionen des zu ersetzenden Systems gemacht. Und ich habe einen USB-Stick mit dem Wiederherstellungstool von Veeam erstellt.
Dann habe ich die alte M.2-SATA SSD entfernt und die NVMe-SSD installiert.
Darauf habe ich dann ein frisches Windows 10 installiert.
Danach habe ich den Rechner vom Wiederherstellungstool gestartet, das Laufwerk C:\ von dem frisch installierten System entfernt, die EFI-Partition aber behalten und dann das Laufwerk C:\ aus dem Backup an die Stelle des frisch installierten Windows 10 gesetzt (ohne die Partitionsgröße zu ändern).
Oh, das geht? Nein, eigentlich geht das nicht.
So war es dann auch in meinem Fall: nach der Wiederherstellung fuhr der Rechner nicht hoch -> Bluescreen.
Also habe ich dann vom Windows 10 USB-Installationsstick gebootet und bin dort über Computerreparaturoptionen in die Eingabeaufforderung gegangen.
Dort fing ich dann wieder mit den üblichen Aktionen an, um Bootmanager und EFI-Partition zu reparieren:
1) EFI-Partition neu formatiert (format T:/FS:FAT32)
2) bcdboot c:\windows /s t: /f UEFI
3) bootrec/fixboot
Bei 3) kam allerdings wieder die "schöne" Meldung: Zugriff verweigert - für die es im Netz zwar viele Tutorials gibt, von denen aber noch nie eins in meinen Fällen geholfen hat. Von daher war ich auch in diesem Fall wieder pessimistisch, irgendwas erfolgreich repariert zu haben.
Joa - und dann nochmal neu gestartet und plötzlich fuhr Windows fehlerfrei hoch.
Ich muss ehrlich sagen: aus sachlicher Sicht habe ich nun eigentlich mit bcdboot und bootrec etc. nichts anderes gemacht als 1 Dutzend Mal zuvor auch - abgesehen von der Verzweifelungstat mit dem Überbügeln der frischen Win 10 Installation durch Restore des C:-Partition und Formatieren und Reparieren der EFI-Partition. Machte eigentlich keinen wirklichen Sinn - war irgendwie eine Verzweifelungstat. Keine Ahnung, ob dadurch besser reparierbare Partitionierungen entstanden waren oder was auch immer es war, was in diesem Fall den Unterschied gemacht hat.
Scheint für mich generell ein ziemlich undurchsichtiges Thema zu sein, weil eben auch keine der Anleitungen im Netz den Anspruch erhebt garantiert zu funktionieren. Kann klappen, kann aber auch schief gehen.
Was lernt man daraus: entweder gar keine Zeit mit diesem Mist verschwenden und direkt neu installieren, oder die Bereitschaft mitbringen lange an dem Problem rumzufrickeln und es immer wieder ein bisschen anders zu versuchen, bis es dann vielleicht irgendwann mal funktioniert - warum auch immer!
Grüßerle,
euer Colt.
Unglaublich, aber wahr: es funktioniert!
Komischerweise lässt sich nicht präzise feststellen, woran es lag.
Was ich zuletzt gemacht hab:
Ich habe mit dem kostenlosen Veeam Backup Agent für Windows (Free) ein Backup der Systempartitionen des zu ersetzenden Systems gemacht. Und ich habe einen USB-Stick mit dem Wiederherstellungstool von Veeam erstellt.
Dann habe ich die alte M.2-SATA SSD entfernt und die NVMe-SSD installiert.
Darauf habe ich dann ein frisches Windows 10 installiert.
Danach habe ich den Rechner vom Wiederherstellungstool gestartet, das Laufwerk C:\ von dem frisch installierten System entfernt, die EFI-Partition aber behalten und dann das Laufwerk C:\ aus dem Backup an die Stelle des frisch installierten Windows 10 gesetzt (ohne die Partitionsgröße zu ändern).
Oh, das geht? Nein, eigentlich geht das nicht.
So war es dann auch in meinem Fall: nach der Wiederherstellung fuhr der Rechner nicht hoch -> Bluescreen.
Also habe ich dann vom Windows 10 USB-Installationsstick gebootet und bin dort über Computerreparaturoptionen in die Eingabeaufforderung gegangen.
Dort fing ich dann wieder mit den üblichen Aktionen an, um Bootmanager und EFI-Partition zu reparieren:
1) EFI-Partition neu formatiert (format T:/FS:FAT32)
2) bcdboot c:\windows /s t: /f UEFI
3) bootrec/fixboot
Bei 3) kam allerdings wieder die "schöne" Meldung: Zugriff verweigert - für die es im Netz zwar viele Tutorials gibt, von denen aber noch nie eins in meinen Fällen geholfen hat. Von daher war ich auch in diesem Fall wieder pessimistisch, irgendwas erfolgreich repariert zu haben.
Joa - und dann nochmal neu gestartet und plötzlich fuhr Windows fehlerfrei hoch.
Ich muss ehrlich sagen: aus sachlicher Sicht habe ich nun eigentlich mit bcdboot und bootrec etc. nichts anderes gemacht als 1 Dutzend Mal zuvor auch - abgesehen von der Verzweifelungstat mit dem Überbügeln der frischen Win 10 Installation durch Restore des C:-Partition und Formatieren und Reparieren der EFI-Partition. Machte eigentlich keinen wirklichen Sinn - war irgendwie eine Verzweifelungstat. Keine Ahnung, ob dadurch besser reparierbare Partitionierungen entstanden waren oder was auch immer es war, was in diesem Fall den Unterschied gemacht hat.
Scheint für mich generell ein ziemlich undurchsichtiges Thema zu sein, weil eben auch keine der Anleitungen im Netz den Anspruch erhebt garantiert zu funktionieren. Kann klappen, kann aber auch schief gehen.
Was lernt man daraus: entweder gar keine Zeit mit diesem Mist verschwenden und direkt neu installieren, oder die Bereitschaft mitbringen lange an dem Problem rumzufrickeln und es immer wieder ein bisschen anders zu versuchen, bis es dann vielleicht irgendwann mal funktioniert - warum auch immer!
Grüßerle,
euer Colt.
Also ich lege einfach eine FAT32-formattierte EFI-Partition, eine Micorosft-Reserved und eine Windowspartiton an, die mindestens so groß ist wie die ursprüngliche Partition, und kopoiere dann einfach mit ddrescue die "C:-Partition" da drauf.
Danach ein bcdboot mit passenden parametern und die Kisten laufen dann i.d.R. Wenn Du mit bcdboot keine erfolg hattest, hast Du die C-Partotion anscheinen nicht korrekt kopiert. (1:1-Image!).
Dort fing ich dann wieder mit den üblichen Aktionen an, um Bootmanager und EFI-Partition zu reparieren:
1) EFI-Partition neu formatiert (format T:/FS:FAT32)
2) bcdboot c:\windows /s t: /f UEFI
1) EFI-Partition neu formatiert (format T:/FS:FAT32)
2) bcdboot c:\windows /s t: /f UEFI
3) bootrec/fixboot
Dei UEFi ist das unnötoig. Der Bootrecord der Patrtition wird von UEFi überhaupt nicht angefaßt. Das ist nur bei Legacy-Boot notwendig.
Aber schön daß es geklappt hat.
lks
