ThinkPad 25th Anniversary Das Grauen: Windows lässt sich nicht installieren, Linux schon

Ja, die Platte wurde als Bootoption auch immer angezeigt, wenn ohne ein anders Medium (USB Stick oder USB DVD) gebootet wurde.

Das heißt im Umkehrschluss, dass jedes gebootete USB-Medium jedes andere Medium abweist bzw. als nicht existent darstellt. Und das heißt dann eben, dass da doch etwas mit TPM ist, bei dem man ja auch keine Hardware sieht, die nicht im TPM-Chip ausdrücklich registriert ist und wo die Datenträger außerdem noch verschlüsselt sind. Das würde erklären, warum man nichts installieren kann: Der Schlüssel sitzt im BIOS/UEFI, der WINDOWS-Stick kann nur sich selbst booten. LINUX ignoriert TPM, muss nachträglich extra verschlüsselt werden und kann den Key nicht BIOS/UEFI ablegen.

Ich habe immer noch irgendwie meine erste Vermutung im Kopf - irgendein Flash Vorgang der Firmware ist schief gelaufen, ohne dass es gemeldet worden wäre.

Vielleicht die Firmware vom TPM.
 
War vielleicht Bitlocker ab Werk aktiviert? Kann man nicht TPM "löschen" und/oder deaktivieren?
 
War vielleicht Bitlocker ab Werk aktiviert? Kann man nicht TPM "löschen" und/oder deaktivieren?

Wenn man in das WINDOWS reinkommt, dort TPM deaktiviert und dann im BIOS deaktiviert, kann man TPM abschalten. Vorher muss man aber zwingend Bitlocker deaktivieren und entschlüsseln, sonst sieht man seine Platte nach einem Reboot nie wieder oder man hat den Schlüssel vorher ausgelesen und irgendwo abgespeichert und kann ihn neu eingeben.

Das gleiche passiert auch bei einem BIOS-Update über Lenovo Vantage, bei dem man aber vorher zweimal ausdrücklich gewarnt wird, den Bitlockerschlüssel bitte auszulesen und bereitzuhalten.

Denn nach dem BIOS-Update will das BIOS den Schlüssel neu eingegeben haben, ansonsten darf man mit diskpart seine Platte platt machen und muss WINDOWS neu installieren, was z.B. bei einem Lenovo Yoga Book mit seinen 985 Treibern so amüsant ist wie eine Zahnwurzelbehandlung ohne Narkose... ;)
 
Das TPM kann man AFAIK auch aus dem UEFI heraus löschen, zumindest aber deaktivieren.
 
- Die Bitlocker Verschlüsselung hebe ich immer als erstes auf, so war es auch hier. Bevor irgendwelche Updates gemacht werden.
- Ich müsste mich schwer täuschen, aber ich habe alle möglichen Kombinationen durchgehabt, und meine auch dabei TPM im BIOS mal deaktiviert (und wieder andersrum) zu haben

Naja, wie gesagt, ich warte erstmal.
 
Naja, aufheben muss man den Bitlocker eigentlich garnicht - der ist nie automatisch gesetzt...
 
Naja, aufheben muss man den Bitlocker eigentlich garnicht - der ist nie automatisch gesetzt...
Nach dem Auspacken der Geräte oder einer Recoveryinstallation steht der Bitlocker immer als "Aktiv, wartet auf eine Verbindung mit einem Microsoft Konto" bzw. so ähnlich. In den Einstellungen gehe ich dann immer auf "Verschlüsselung aufheben" und das System sagt: "Sie können weiterarbeiten, während die Verschlüsselung aufgehoben wird." So ähnlich jedenfalls liest sich das, habe den exakten Wortlaut nicht zur Hand.
 
Problem Inkompatibilität von bestimmten SSD mit Windows 10
das Problem hatte ich mit einer SSD von S*****K. Sogar auf meinem Tischrechner. Zweimal das Fenster des Grauens. Jetzt habe ich eine billige Kingston drinnen. Ach ja, LUBUNTU lief auf dem gleichen Rechner mit der gleichen S*****K ohne Probleme.
 
Beim letzten Update KB4482887 hat WINDOWS 10 den eigenen Microcode gegen Spectre V2 gegen das Retpoline-System von Google ausgetauscht. Dabei wurde versprochen, die ca. 10% bis 20% Geschwindigskeitsnachteile, die durch das MS-Spectre2-Schutzsystem geschaffen wurden, wieder aufzuheben.

Das heißt nun wieder nichts anderes, als das das KB4482887-Update erst das "neue" Retpoline-System installiert hat, und dann die eigenen Microcode-Veränderungen in der CPU zurückgeschrieben hat. Vielleicht sind beim Rückschreiben des Microcodes durch das Update massive Fehler aufgetreten.

Ein Indiz dafür wäre, dass es nur "certain machines" betrifft, also ganz bestimmte Maschinen und CPUs, die aber nicht namentlich genannt werden. Nicht unwahrscheinlich, dass die relativ neue CPU des T25 dabei ist, um Schadenersatzforderungen wegen nicht erreichter CPU-Leistung zu verhindern...

Eine weiteres Indiz wäre, dass Linux schon immer Retpoline von Google verwendet hat, aber WINDOWS erst nicht ... und jetzt eben doch. Deswegen hat Linux keine Probleme mit der Veränderung des Microcodes...

--------------------------------

Die Sache wird wohl so gelaufen sein:


  • Das Update installiert Retpoline und verändert den Mircrocode der CPU zum Originalzustand zurück, schafft es aber beim Reboot nach dem Update nicht, den WINDOWS-Kernel auszutauschen bzw. anzupassen. Deswegen gibt es eine erste Fehlermeldung direkt nach dem Reboot: WINDOWS-Kernel mit Spectre2-Schutz trifft auf Original-CPU ohne Spectre2-Microcode-Veränderung.
  • Alle folgenden Versuche per USB-Stick scheitern nun daran, dass die Kernel auf dem USB-Stick mit WINDOWS10-Versionen seit 1803 erstellt wurden, die noch auf den veränderten Microcode mit Spectre2-Schutz setzen, das beträfe dann auch die "kleinen Kernel" von WINDOWS-PE auf dem Stick vor der Installation: Microcode ist Microcode.
  • Da der CPU-Microcode aber nicht mehr verändert ist und das Original die CPU zurückgeschrieben wurde, scheitern alle WINDOWS-Kernel mit Spectre2-Schutz an der CPU. Dies könnte man testen, in dem man eine ganz frühe Version von WINDOWS 10 (vermutlich 1709 und früher) installiert, die noch keinen Spectre2-Schutz kennt.
  • ... oder beim Zurückschreiben des CPU-Microcodes durch das Update ist etwas Grundlegendes schief gelaufen, dann müsste aber auch der LINUX-Kernel schlappmachen. Macht er aber nicht, also ist es ein Problem des WINDOWS-Kernel: LINUX, dass von Anfang an auf Retpoline gesetzt hat, ist dagegen mit seinem Kernel gegen die MS-CPU-Microcode-Veränderung immun.


Hola da kann ich dich beruhigen Windows schreibt keinen Microcode ins Bios
und zum Spectre/Microcode Patch-chaos:
Retpoline verträgt sich mit den Biosänderungen/Microcodes.

Siehe auch z.B. hier: https://thinkpad-forum.de/threads/2...s-notwendig)?p=2183124&viewfull=1#post2183124

Ich habe das grade getestet ....
 
Das heißt nun wieder nichts anderes, als das das KB4482887-Update erst das "neue" Retpoline-System installiert hat, und dann die eigenen Microcode-Veränderungen in der CPU zurückgeschrieben hat. Vielleicht sind beim Rückschreiben des Microcodes durch das Update massive Fehler aufgetreten.
Die Sache wird wohl so gelaufen sein:


Das Update installiert Retpoline und verändert den Mircrocode der CPU zum Originalzustand zurück, schafft es aber beim Reboot nach dem Update nicht, den WINDOWS-Kernel auszutauschen bzw. anzupassen. Deswegen gibt es eine erste Fehlermeldung direkt nach dem Reboot: WINDOWS-Kernel mit Spectre2-Schutz trifft auf Original-CPU ohne Spectre2-Microcode-Veränderung.
Alle folgenden Versuche per USB-Stick scheitern nun daran, dass die Kernel auf dem USB-Stick mit WINDOWS10-Versionen seit 1803 erstellt wurden, die noch auf den veränderten Microcode mit Spectre2-Schutz setzen, das beträfe dann auch die "kleinen Kernel" von WINDOWS-PE auf dem Stick vor der Installation: Microcode ist Microcode.
Da der CPU-Microcode aber nicht mehr verändert ist und das Original die CPU zurückgeschrieben wurde, scheitern alle WINDOWS-Kernel mit Spectre2-Schutz an der CPU. Dies könnte man testen, in dem man eine ganz frühe Version von WINDOWS 10 (vermutlich 1709 und früher) installiert, die noch keinen Spectre2-Schutz kennt.
... oder beim Zurückschreiben des CPU-Microcodes durch das Update ist etwas Grundlegendes schief gelaufen, dann müsste aber auch der LINUX-Kernel schlappmachen. Macht er aber nicht, also ist es ein Problem des WINDOWS-Kernel: LINUX, dass von Anfang an auf Retpoline gesetzt hat, ist dagegen mit seinem Kernel gegen die MS-CPU-Microcode-Veränderung immun.

Dass das mit der veränderten CPU-Firmware Blödsinn ist hat ja bereits Moronoxyd gleich aufgeklärt:
Wenn Windows über ein Update den Microcode einer CPU ändert, wird dieser nicht dauerhaft verändert, sondern er wird beim Booten geladen und ist nach dem Herunterfahren/Neustarten weg, wenn er nicht wieder geladen wird:
https://www.thomas-krenn.com/de/wiki...Betriebssystem
https://support.mozilla.org/en-US/kb/microcode-update ("Microcode updates do not persist across reboot")
Da Windows niemals den Microcode dauerhaft verändert hat, muss das Update mit Retpoline diesen auch nicht zurück ändern.
Sehr guter Einwand und alles richtig, aber der Effekt ist am Ende derselbe: Wenn das Update nicht so funktioniert, wie es soll, wird beim Start ja wieder der Spectre2-Microcode geladen, der irgendwie nicht mit dem neuen WINDOWS-Kernel zusammenarbeitet. Das Problem, ob der Code temporär oder dauerhaft in die CPU oder das BIOS eingetragen wird, ändert sich ja nicht.

Wenn Du den von Dir im ersten Post verlinkten Beitrag richtig gelesen hättest, hätte Dir auch klar sein dürfen, dass Retpoline noch nicht automatisch aktiviert ist, sondern dazu momentan noch manuell anzulegende Registry-Einträge benötigt. Diese werden von Microsoft erst in kommenden Updates nachgereicht.

Zudem dürften die momentan ladbaren Installations-Imagaes von Win10 1809 das betreffende Update-Rollup noch gar nicht installiert haben, bei mir war dies vor zwei Tagen jedenfalls noch nicht der Fall!
 
Hola da kann ich dich beruhigen Windows schreibt keinen Microcode ins Bios und zum Spectre/Microcode Patch-chaos:
Retpoline verträgt sich mit den Biosänderungen/Microcodes.

Ich habe das grade getestet ....

Ja, aber ein blöder SATA/SSD-Fehler im T25 wäre jetzt doch wirklich bitter enttäuschend, nachdem wir uns alle derart hineingesteigert haben:
Für so einen popligen Mangel denke ich doch nicht ernsthaft länger als ein Minute nach... :D
 
Ja, aber ein blöder SATA/SSD-Fehler im T25 wäre jetzt doch wirklich bitter enttäuschend, nachdem wir uns alle derart hineingesteigert haben:
Für so einen popligen Mangel denke ich doch nicht ernsthaft länger als ein Minute nach... :D
Du sollst auch nicht nur nachdenken, sondern dich informieren und die Fakten verstehen lernen, bevor du wilde Theorien in den Raum wirfst.
 
Da du CRITICAL_PROCESS_DIED erwähnt hast ist es höchstwahrscheinlich die SSD.

Fehlermeldung wie immer bei Windows 10 nichtssagend. Keine Dumps vorhanden. Anderer Bluescreen wurde mit "UNEXPECTED_STORE_EXCEPTION" betitelt. Es war zwar ein Dell Laptop, jedoch gab es nach dem Tausch der SSD keine Abstürze mehr.

Danke Microsoft ! :facepalm:
 
Da du CRITICAL_PROCESS_DIED erwähnt hast ist es höchstwahrscheinlich die SSD. Fehlermeldung wie immer bei Windows 10 nichtssagend. Keine Dumps vorhanden. Anderer Bluescreen wurde mit "UNEXPECTED_STORE_EXCEPTION" betitelt. Es war zwar ein Dell Laptop, jedoch gab es nach dem Tausch der SSD keine Abstürze mehr. Danke Microsoft ! :facepalm:

Kann ich hier nicht sagen, weil - wie weiter oben beschrieben - auch der Einbau einer 1TB SATA SSD 2280 nichts an dem Verhalten geändert hat. Oder es müsste bei beiden SSDs eine Epidemie ausgebrochen sein. Oder die Sache ist ansteckend. :cool:
 
Um mal hier auf dem Laufenden zu bleiben: Am Freitag, den 8.3. hatte ich es an Servion versandt, am 11.3. ist es dort eingegangen. Meine Nachfrage am 12.3. wurde so beantwortet: (Zitat):

Ihr Notebook wurde uns erst gestern (11.03.2019) zugestellt.
Daher können wir noch keine Aussage treffen.
Wenn Sie ihr Gerät bis zum 20.03.2019 nicht zurück haben, können Sie nochmals gerne nachfragen.


:( Hatte ich mir eigentlich etwas auskunftsfreudiger vorgestellt. Morgen ist der 19.3. und ich werde dann mal Übermorgen, wenn sich da nichts Neues ergibt, nochmal nachfragen. Es hätte mich ja doch mal zwischendurch eine Wasserstandsmeldung interessiert.

In Zukunft setze ich jetzt erstmal ohnehin auf das Surface Book 2, der Support von Microsoft läßt ja auch zum Teil gräußliches hören, aber nach meinen letzten Erfahrungen mit Thinkpads kann es ja nicht unbedingt schlimmer/anders werden. Meine bisherigen Erfahrungen mit dem Surface Pro 4 und dem Lumia 950 XL (das immer noch beste Phone für mich) waren jedenfalls exzellent.

Erstaunlich, das ich als alter OS/2ler doch beim Microsoft Park gelandet bin. :rolleyes:

Surface Book 2.jpg

- - - Beitrag zusammengeführt - - -

Update: auf meine telefonische Nachfrage teilte Servion gerade mit: Hardwaredefekt Mainboard. Man war dort auch an der Installation verzweifelt und hat alle Komponenten ausgebaut, selbst dann ging es mit dem Notrest nicht.

Mainboard wurde getauscht und so kommt das Gerät wohl Ende der Woche wieder. Bin mal gespannt.
 
Zuletzt bearbeitet:
Das Gerät ist heute von Servion eingetroffen. Optisch etc. sieht es aus wie zum Zeitpunkt des Versendens dorthin, ein vorinstalliertes Windows 10 funktioniert.

Im Servicebericht steht: Mainboard getauscht.

Ich werde dann zu Hause das Lenovo Recovery Medium benutzen und schauen, ob das alles dann funktioniert, aber wieso sollte es nicht.

Servion kann ich daher sehr empfehlen, als einzigen Verbesserungspunkt würde ich doch gerne die Kommunikation während der Reparaturzeit ansprechen wollen, es gab grundsätzlich keine Benachrichtigung (eine Art Statusmeldung) über den Vorgang an sich.

So kann ich nur die subjektive Empfehlung auf Grund meiner Erfahrungen aussprechen: selbst wenn eine Vorort Garantie möglich wäre, das Gerät lieber einschicken!
 
Freut mich für dich.

Deiner Empfehlung für Servion (statt VOS) kann ich mich aus eigener, mehrfach positiver Erfahrung anschließen.

Was die Benachrichtigungen angeht: der Wunsch nach denselben speist sich m.E. aus der Erfahrung mit unzuverlässiger Dienstleistung. Am Ende ist für mich ein Dienstleister, der sich nicht die Zeit für Fortschrittsmeldungen nimmt, sich unnötiges Prozess- und QM-Getue spart und stattdessen einfach gut arbeitet, der beste Kompromiss.
 
Zuletzt bearbeitet:
  • ok1.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen
Zurück
Oben