Vorsicht bei Wechsel von M.2 SATA auf M.2 PCIe SSD

[Nero24]

Hallo zusammen,

aus aktuellem Anlass hier eine Warnung für User, die vor haben ihre M.2-SATA-SSD durch eine M.2-PCIe-SSD zu ersetzen, wie ich es kürzlich gemacht habe.

Eigentlich ist das kein Hexenwerk. Vorab vergewissert man sich, dass in der Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\stornvme der Parameter Start auf 0 steht, damit der NVMe-Treiber bereits beim Booten geladen wird und Windows 10 von der neuen PCIe-NVMe-SSD wird booten können. Zusätzlich im Unterordner Parameters checken, dass da kein Parameter StartOverride steht. In diese erste Falle war ich zunächst getappt. Falls ja, diesen Eintrag einfach löschen, sonst kann das System nicht von der neuen SSD booten und stürzt mit der Meldung Inaccessible Bootdevice ab. Dann die bestehende Installation per Image-Software (Macrium Reflect oder TrueImage) sichern, SSDs umbauen und auf die PCIe-SSD zurückspielen. Das war's normalerweise.

Bisher hat das bei verschiedensten Systemen auch schon perfekt funktioniert. Da wurde die bestehende Installation jedoch stets von einem älteren System – meist mit SATA-SSD oder -HDD – auf ein neues System mit NVMe-PCIe-SSD übertragen, nicht von M.2-SATA auf M.2-PCIe auf demselben System. Zwar konnte auch ich booten und weitestgehend normal arbeiten, aber es gab immer wieder sporadische Probleme mit dem Standby. Manchmal funktionierte Standby, dann wachte das System nach ein paar Minuten unvermittelt wieder auf und verabschiedete sich mit einem Bluescreen, meist verursacht von hal.dll, ntoskernel.exe und pshed.dll.

Zunächst schob ich das Standby-Problem auf die Grafikkarte, die ich ungünstigerweise parallel zur SSD noch mit gewechselt hatte und probierte etliche Grafiktreiber. Im normalen Betrieb war eigentlich alles ok, die Standby-Probleme jedoch blieben. Interessant wurde es bei der Installation der nächsten Windows-Updates. Hier verabschiedete sich das System beim Reboot und anschließendem Einspielen der Updates mit einem WHEA Uncorrectable Error Am aufschlussreichsten war jedoch der Versuch des Systems dabei ein Dump-File zu erzeugen. Das war anscheinend nicht möglich, denn die Fortschrittsanzeige verharrte bei 0%. Das erst brachte mich auf die Idee, dass die Probleme nicht an der neuen Grafikkarte liegen könnten, sondern an der SSD, die in dem Moment offenbar nicht beschreibbar war. Modell war eine Samsung 970 Evo.

Ich probierte das Exemplar zunächst einmal in einem anderen, jungfräulichen System. Dort traten die Probleme nicht auf. Ein Defekt an der SSD konnte also ausgeschlossen werden. Ich überlegte daher, was an meinem System anders war als an dem jungfräulichen. Eigentlich nur, dass zuvor im M.2-Slot eine SATA-AHCI-SSD gesteckt hatte. Ich sorgte also per CMOS-Clear (nicht per Load Setup Defaults im BIOS!) dafür, dass die Plattform zurückgesetzt wurde und stellte anschließend alle sichtbaren Optionen wieder so ein wie vorher. Und siehe da. Seit diesem Zeitpunkt sind die Standby- und Update-Probleme weg! Anscheinend war bei dem Wechsel von SATA-AHCI auf NVMe-PCIe am M.2-Slot irgendein versteckter BIOS-Parameter noch falsch gesetzt, der erst durch den CMOS-Clear korrigiert wurde.

Lange Rede kurzer Sinn: beim Wechsel von M.2-SATA-AHCI- auf M.2-PCIe-NVMe-SSD am M.2-Slot desselben Systems sicherheitshalber einen CMOS-Clear durchführen. Mainboard war in meinem Fall ein ASUS Prime B350-PLUS. Kann natürlich ein BIOS-Bug des Boards sein, aber wer sich nicht auch tagelang mit solchen Problemen aufhalten will, sollte das BIOS sicherheitshalber zurücksetzen bei einem solchen Umbau.

 

[E555user]

...beim Wechsel von M.2-SATA-AHCI- auf M.2-PCIe-NVMe-SSD am M.2-Slot desselben Systems sicherheitshalber einen CMOS-Clear durchführen.

Das fällt dann wohl in die Kategorie undokumentierte UEFI Features des MB-Herstellers.

Ich denke mir so manches mal es war früher gar nicht so übel wenn man (nur) Jumper umstecken musste. Nur beim SCSI Kontroller hatte ich einen per Kippschalter am Slotblech flexibler gemacht...

 

[Nero24]

Naja, M.2 ist ja nur der Slot. Die Funktion dagegen ist eine völlig unterschiedliche, je nachdem, welcher SSD-Typ da drinsteckt. Im Falle von SATA/AHCI muss ein SATA-Port vom SATA-Controller an den M.2-Slot geroutet werden, im Falle einer PCIe/NVMe-SSD hingegen vier PCIe-Lanes, also was völlig unterschiedliches. Dabei wird wohl irgendwas schiefgegangen sein beim SSD-Wechsel ohne CMOS-Clear, irgendwas vom SATA-Controller steckte noch am M.2-Port fest obwohl gar keine SATA-SSD mehr dranhing. Bin nur froh es rausgefunden zu haben, wollte schon die Grafikkarte und als nächstes wohl die SSD reklamieren

 

[MagicEye04]

Als ich eine M.2-Sata auf eine normale SATA geklont hatte, wollte die dann auch nicht mehr starten.

Da es auch ein ASUS Prime B350, allerdings der kleine Bruder A-M war, könnte das womöglich auch irgendwie daran gelegen haben, dass das Bios da noch irgendwelche undokumentierten Dinge macht...

 

[Nero24]

Ich hatte gestern noch einen Fall, der allerdings anders geartet war, aber auf's Gleiche rauslief: ich konnte nicht booten!

Hier wurde eine Installation von 2,5" SATA-SSD auf M.2 NVMe-SSD geklont. In diesem Fall war es ein ASUS A320M-A. Mit meiner obigen To-Do-Liste an der Hand konnte eigentlich nichts mehr schiefgehen; dachte ich zumindest Allerdings bin ich in eine weitere Falle getreten, die ich nicht auf dem Schirm hatte.

Ich hab die M.2-SSD in den freien Slot geschraubt, die 2.5"-SSD drangelassen und TrueImage von USB-CD gebootet. Was ich nicht mehr auf dem Schirm hatte: ich schalte immer USB Legacy ab, damit USB-Sticks oder externe Festplatten die Bootreihenfolge nicht durcheinander bringen. Es hätte mir also schon komisch vorkommen müssen, dass ich von USB-DVD booten konnte obwohl USB-Legacy aus war. Im UEFI-Modus dagegen ist das USB-Laufwerk jederzeit greifbar. TrueImage bootete also von mir unerkannt im UEFI-Modus, während die Installation im BIOS-Modus vorlag.

Aber selbst das hätte mich wohl noch nicht in Alarmbereitschaft versetzt, da ich ja den Modus "Clone Disk" wählte. Klonen heißt für mich 1:1 übertragen. Also selbst wenn TrueImage im UEFI-Modus lief, wäre ICH davon ausgegangen, dass die bestehende Installation 1:1 von der 2.5"-SSD auf die M.2-SSD übertragen wird. Tja, Pustekuchen! Von mir unerkannt klonte TI die Installation zwar auf die M.2, stellt dabei allerdings das Partitionsformat von MBR auf GPT um. Das fiel mir allerdings nicht gleich auf, sondern erst, nachdem ich eine Stunde lang vergebens versucht hatte von der M.2. zu booten. Erst nachdem ich schon halb verzweifelt von der Windows-Boot-DVD startete und mittels diskpart die Laufwerke durchging, fiel mir auf, dass bei der M.2 bei GPT ein * angezeigt wurde.

Ich cleante die M.2 also nochmal, aktivierte USB Legacy im BIOS, bootete TrueImage im BIOS-Modus von USB-DVD und klonte nochmal. Nun wurde auf der M.2 eine MBR-Partition angelegt und ich konnte problemlos von der geklonten Installation booten. Wieder 2 Stunden für die Katz, aber wieder was gelernt

 

[MagicEye04]

Das musste ich auch schon ein paar Mal feststellen, dass True Image versucht, mitzudenken und dann irgendwas verändert.

 

[Nero24]

dass True Image versucht, mitzudenken

Genau das trifft es perfekt: "versucht mitzudenken" Statt einfach zu machen, was man ihm sagt

 

[Scour]

Als täglicher Anwender von TI am Arbeitsplatz boote ich eigentlich immer im BIOS-Mode, zumindest auf PCs (auf vielen Notebooks nicht mehr möglich). Ob die zu sichernde Partition im UEFI oder zusätzlich sogar im Secure Boot ist macht da keinen Unterschied. Images funktionierten bisher immer.

Allerdings gibt es in meiner PC-Testumgebung noch keine NVME-SSDs, kommt wahrscheinlich mit den nächsten Test-PCs

 

[eratte]

Ich hatte noch keine Probleme mit TI und meinen PCIe NVMe SDDs.

 

[Holt]

Dabei wird wohl irgendwas schiefgegangen sein beim SSD-Wechsel

Dafür gibt es einen Pin am M.2 Slot, Pin 69. Der ist auf SATA SSD mit Masse verbunden und bei M.2 PCIe SSDs soll er nicht verbunden sein. Somit kann das Board erkennen was für eine SSD im Slot steckt, dazu gibt das Board über einen Vorwiderstand Spannung an diesen Pin und misst zugleich die Spannung hinter dem Vorwiderstand. Fällt sie auf 0V, ist eine M.2 SATA SSD eingesteckt. Wenn eine Reset des BIOS nötig war, so hat das BIOS entweder einen Bug oder es war dort fest eingestellt das eine M.2 SATA SSD verbaut ist, statt die Einstellung auf AUTO zu lassen, denn nur in der Einstellung AUTO wird dann das Ergebnis der Erkennung über Pin 69 verwendet, die anderen Einstellungen überschreiben dieses hingegen.

 

[Nero24]

@Holt: an der Erkennung kann's eigentlich nicht gelegen haben, sonst wäre die M.2-PCIe-SSD ja nicht mal erkannt worden wenn der SATA-Controller noch dorthin verbunden worden wäre. Es muss irgendeine Kleinigkeit vom BIOS "vergessen" worden sein, was für den REIBUNGSLOSEN Betrieb notwendig gewesen wäre. Ich gehe auch von einem BIOS-Bug aus.

 

[PlayerOne]

Danke für den Tipp, wenns soweit ist werde ich dran denken.

 

[ghostadmin]

Bei Win10 mit einer vom Hersteller (HP) angelegten Recovery Partition war es mir mit TI 2016 oder 2019 auch nicht möglich ein funktionierendes Image zu machen das auf der neuen SSD funktionierte.
Ich vermute weil die Reihenfolge der Partitionen nicht mehr stimmte.
Über Clone ging es dagegen.

Gibt es da eine bessere Alternative? Mir kommt vor TI wird immer schlechter.
Clonezilla kann ja anscheinend keine Kopie auf eine kleinere Disk.

 

[Scour]

Ich probiere mal immer Freeware-Alternativen aus, aber bleibe dann doch wieder bei meinem aktuellsten Acronis (2018). Die Freeware-Alternativen waren entweder sehr langsam, grausam von der Bedienung, konnten Paritionen/HDDs/SSDs nur mit absolut gleicher Größe händeln, fanden keine Datenträger bei neueren Mainboards/Laptops oder es funktionierte so gut wie nix.

So lange ich nur Windows klone funktioniert Acronis gut. GPT-Datenträger können aber nervig sein wegen der ganzen zusätzlichen Partitionen, Cloning funktionierte aber bisher.

Sollte wirklich jemand was Ähnlich Gutes empfehlen können das nicht teurer als Acronis ist könnte er nen Tipp geben

 

[ghostadmin]

Das andere Problem war das TI nicht immer bootet bei jedem Rechner oder das eine alte Version beim Imaging funktionierte aber die neue nicht.

 

[eratte]

Konnte ich nicht feststellen, wenn dann liegt es an den BIOS Einstellungen (UEFI only oder CSM aktiv)

 

[PT428]

"Des Menschen Wille ist sein Himmelreich" - und weil einige Leute den Verblödungsmedien alles glauben, gab es hier Wünsche zum Umbau von SATA-SSD auf die angeblich extrem schnelleren PCIe NVMe im M2.
Habe bei den betreffenden ASUS Prime B450M-K und M-A zuerst die Crucial P2 CT500 eingebaut und damit den PC hoch gefahren. Dann mittels Clonezilla die eingebaute SSD (Kingston SA400 oder Intenso mit jeweils 240 GB) auf eine externe HD gesichert. Anschließend die SSD ausgebaut und wiederum per Clonezilla eine Rücksicherung auf die Crucial gemacht. Und dann nach der Bootänderung im BIOS das System hoch gefahren. Dabei kam bei jedem umgebauten PC eine Fehlermeldung zum Filesystem. Deshalb habe ich mal scandisk laufen lassen. Und die Systeme laufen seitdem ohne jegliche Probleme, sind ja 4-5 Tage in der Woche für Home-Office im Einsatz. Die zuerst ausgebaute SSD habe ich an einem anderen System platt gemacht, dann wieder eingebaut und als zusätzlichen Speicherplatz eingerichtet (den eh niemand braucht). Natürlich zeigt Benchmurks jetzt bessere Werte beim Datenträgerdurchsatz an, aber in der täglichen Home-Office-Nutzung merkt man davon absolut nichts. Zumal die Crucial P2 CT500 anscheinend zu den lahmeren Typen gehört.

 

[MagicEye04]

Muss so ein Stammtisch-Kommentar hier sein, wo er nichts verloren hat? Versuchs einfach woanders...

Bei Win10 mit einer vom Hersteller (HP) angelegten Recovery Partition war es mir mit TI 2016 oder 2019 auch nicht möglich ein funktionierendes Image zu machen das auf der neuen SSD funktionierte.
Ich vermute weil die Reihenfolge der Partitionen nicht mehr stimmte.
Über Clone ging es dagegen.

Gibt es da eine bessere Alternative? Mir kommt vor TI wird immer schlechter.
Clonezilla kann ja anscheinend keine Kopie auf eine kleinere Disk.

TI versucht halt mit immer mehr Funktionsumfang neue Kundschaft zu generieren.
Und wenn man zu viel will, funktioniert das manchmal nicht.
Wenn der Bediener die Automatik laufen lässt, dann kommt halt das raus, was die Automatik für sinnvoll hielt.

Clonezilla kopiert hingegen stur nach Plan und notfalls auch bitweise im Rohformat.
Auf kleinere Geräte geht auch, man muss dann halt manuell die Partitionen ein wenig Verkleinern vorher und natürlich geht das dann auch nur noch Partitionsweise, nicht mehr bit für bit.

 

[ghostadmin]

Ich nutze TI ja schon sehr lange aber das einzige neue was mir aufgefallen war in den letzten Jahren war die Funktion mit Universal Restore.
Habs auch manuell mit Image nicht immer hinbekommen bzw. hat dann einfach nicht gebootet.

Wenn die neue Disk min. gleich groß ist probier ich vielleicht wirklich mal Clonezilla.

 

[eratte]

Man muss unterscheiden zwischen PE-Bootmedium (das macht an keinem Rechner bei mir Probleme) oder dem auf Linuxbasis (da muss ich schon mal vorher CSM aktiveren im BIOS).

Für TI nehme ich nur noch einen Stick auf PE Basis, nur für das Kombi Medium mit Disk Doctor das auf Linux Basis.

 

[Scour]

Soweit ich mich erinnere funktioniert das Linux-Medium auch mit UEFI-Boot ab TI 2015, kein CSM nötig. Das Bootmenü ist da sehr spartanisch, nur Text mit den Optionen für die 64Bit-Version von Acronis, Systemreport und Boot to Windows.

Funktioniert so auf jeden Fall bis Intel-Systeme der 6. Generation, TI 2018 auch mit Z490-Systemen.