ich hab hier eine Charge von lauter identischen Lenovo Thinkcenters, die ich jetzt im Haus verteilt habe …
Beim Ausrollen von Linux gibt es kein Problem.
Bei Windows10 sieht das etwas anders aus. 3 komplette Computerräume liesen sich (fast) problemlos bespielen (s.u.). Nun hab ich hier 10 Rechner - wie viele noch kommen, kann ich nicht sagen - die nach dem Start von Windows einen Bluescreen liefern.
0x0000000…e Ein erforderliches Gerät ist nicht verbunden, oder es kann nicht darauf zugegriffen werden.
Die Kisten sind so oft umgeschichtet worden, dass es schon arger Zufall wäre, wenn es mit der ersten Kiste außerhalb des Computerraum lauter minimal andere Chips sind.
Hier ist das „unten“, auf das ich oben verwiesen habe. Ein Rechner im Raum hatte das gleiche Verhalten, sein Nachbar nicht. Ich hab dann vom Nachbarn ein Image gezogen und auf diesen Rechner drauf und dann ging es.
Ich hab hier eine MBR-Installation und aus irgendeinem Grund kann ich bootrec /fixboot nicht erfolgreich ausführen, weil „zugriff verweigert“ kommt.
Alle Reparaturanleitungen gehen hier immer von einem UEFI aus - hilft mit nicht weiter. Hat jemand von Euch hier Erfahrungen, wie man so eine Kiste wieder flott bekommt?
„0x0000000…e Ein erforderliches Gerät ist nicht verbunden“
deutet auf Probleme mit dem Massenspeicher hin.
Also schau mal, ob der im AHCI Modus ist.
Sind das M2 SSDs drin?
dann sind die einen mit SATA M2 SSDs, und die andern haben vielelicht
NVMe …
Zur boot reparatur: ich geb dann immer windows repair boot in meine
lieblingssuchmaschine (derzeit ecosia) ein und folge irgend einer Anleitung.
Meist ist es die erste oder zweite, die dann klappt.
/fixmbr
/fixboot
war früher die Compo die gezogen hat.
Inzwischen ist es eher irgendwas mit bcd oder so…
Du kannst auch von einer Windows DVD booten und dort die Reparatur
durchführen: ich hab schon selber erlebt, dass das klappt … aber eher
selten. Gefühlt in einem von 5 Fällen.
Hi,
na ja … sind alles nvme, alle gleich groß, identische Rechner eben.
Ich hab ne ganze Charge bestellt, DAMIT das einheitlich ist. Tja …
Ich hab die Kandidaten jetzt erst mal daheim (2 gehen, 2 nicht).
Ich mach jetzt ein Image der ganzen Platte und dann tausche ich die
Platten mal zwischen den Rechnern - das sollte Klarheit über das prinzipielle Problem geben.
So richtig schlauer bin ich jetzt allerdings nicht.
Bezeichnunge: „gesund“ = kein Bluescreen, „Krank“ = Bluescreen
Konnte auf dem einen Rechner (gesund) zuhause (offline) Windows booten.
Dann hab ich die Platte (gesund) raus und mit der ersetzt (krank), die zum Bluescreen führt. Promt bekomme ich auf dem Gerät (gesund mit Platte krank) auch einen Bluescreen.
Damit sind die Bausteine vom Rechner eigentlich aus dem Rennen.
Es muss wohl an der Platte liegen …
Jetzt hab ich die Platten ausgelesen - das ist der identische Typ in der identischen Version. Demnach kann es die Platte auch nicht sein …
So richtig schlauer bin ich jetzt allerdings nicht.
Bezeichnunge: „gesund“ = kein Bluescreen, „Krank“ = Bluescreen
Konnte auf dem einen Rechner (gesund) zuhause (offline) Windows booten.
Dann hab ich die Platte (gesund) raus und mit der ersetzt (krank), die
zum Bluescreen führt. Promt bekomme ich auf dem Gerät (gesund mit Platte
krank) auch einen Bluescreen.
schlaue idee, das so zu untersuchen.
Damit sind die Bausteine vom Rechner eigentlich aus dem Rennen.
Es muss wohl an der Platte liegen …
Jetzt hab ich die Platten ausgelesen - das ist der identische Typ in der
identischen Version. Demnach kann es die Platte auch nicht sein …
ja, das würde ich auch sagen.
Wie ist es den linboseitig mit den Dingern: sind die gesunden und die
kranken in der gleichen Hardwareklasse?
Oder haben sie nur das gleiche Image?
Vielleicht ist da was an den Partitionsgrößen anders?
Oder der kranke Client wurde an einem Fehlerhaften Kabel/Switch gesynct?
Ich hatte da smal in meiner Testumgebung ZUhause: Client wollte ums
verrecken nicht booten: baugleicher Laptop an anderem Kabel hatte keine
Probleme.
Erst als ein anderer Client, der mit dem selben Image schon ging nach
einem repartiton und sync an dem falschen Kabel auch nciht mehr ging,
kam ich auf das Kabel: ichhabs weggeschmissen und ein anderes genommen:
plötzlich alles wieder super …
… hier triffst du einen „wunden“ Punkt …
Ich hab schon seit längerer Zeit unser Netz in der Schule im Verdacht, dass es nicht ganz sauber ist. Dazu würde passen, dass ich 3 Räume gemacht hab und danach DIESE Probleme anfingen.
Was mir in dem Zusammenhang auch noch auffällt, ist eine ziemliche Unzuverlässigkeit von Linbo-remote in unserem Netz. Da macht nur die Hälfte der Clients einen Reboot, bei den anderen fällt der sync von einer Partition unter den Tisch, … Es ist eine ziemliche Tortur, wenn man jeden Schritt überprüfen muss:
Ist „partition“ gelaufen, hat „format“ funktioniert, …
Das Problem ist halt - wie an jeder Ecke - der Schulträger, denn SEIN Netz kann gar nicht schuld sein … aber ich werd da jetzt Beweise sammeln …
wie wärs mit messen der Netzwerkleitungen? Wo bist Du denn zu Hause (gern auch per PN). Wenn es nicht allzu weit ist würde ich mich gegen Erstattung der Unkosten bereit erklären vorbei zu kommen.
Meist war nach dem Messen klar, dass es das Netzwerk (oder einzelne Leitungen sind) ist.
Auch möglich: Vagabundierende Ströme auf dem Schirm der Leitung. Das ist dann lustig, weil es je nach Konstellation auf tritt und dann auch wieder nicht. Der Verdacht auf vagabundierende Ströme ist immer da, wenn in einem TN C-S-System (in einem Teil des Stromversorgungsnetzes ist der Schutzleiter und der Neutralleiter gemeinsam geführt (PEN-Leiter) Kupferleitungen zum Verteilerswitch führen. Da hilft dann nur das Austauschen von Kupfer gegen Glas.
Um vagabundierende Ströme festzustellen hilft ein empfindliches Zangenamperemeter über die Datenleitung und nachsehen ob da ein Strom angezeigt wird.
VIELEN Dank für dein Angebot - aber Passau dürfte etwas abgelegen sein
Dazu kommt die Human-Firewall des Schulträgers. Fass die Kabel an und du du bist tot …
Darüber hinaus sind wir ziemlich verglasfasert … Aber da ich mittlerweile einen Techniker habe, setze ich den darauf an … nur hat der auch nicht viel mehr Befugnisse
Es war nicht das chkdsk c: sondern es genügte bereits ein bootrec /rebulidbcd.
Damit hätten wir folgende Punkte:
Auch wenn das Netz zickt, so kommen die cloops dennoch korrekt an.
Ich hab das auch mal mit einer md5sum auf Server und Client gecheckt - identisch
Ich brauche ein bootrec /rebuildbcd vom Bootdatenträger von Windows. Hier ist nun die Frage, warum das nötig ist … haut das was beim ntfsclone nicht richtig hin?
Ich würde das mit dem Zangenamperemeter zuerst machen. So etwas sollte ein Techniker in der Werkzeugtasche haben. Aber auch Fluke Geräte zum Zertifizieren von Netzwerkleitungen und Glasfaserstrecken kann man ausleihen.
Wenn der Schulträger so sicher ist dass die Leitungen ok sind, dann müsste er doch über Protokolle der Messungen verfügen, wobei man die auch faken kann.
Gruß
Alois
So abgelegen kann es wieder nicht sein, denn ich war schon mit dem Fahrrad da
Ich brauche ein |bootrec /rebuildbcd| vom Bootdatenträger von
Windows. Hier ist nun die Frage, warum das nötig ist … haut das was
beim ntfsclone nicht richtig hin?
es sit ganz schwierig für mich da Einschätzungen ab zu geben, wenn
direkte Fragen von mir nicht beantwortet werden … und nochmal fragen,
mag ich nicht
deine Fragen oben sind mir durchgerutscht … ist etwas stressig aktuell.
Ja, alle Rechner identisch
Ja, alle Partitionen identisch
Jein, bei den Hardwareklassen: Startconf kopiert und Name ausgetauscht
Netzwerk kann ich wie gesagt nicht ausschließen … aber auch nicht beweisen.
Aktuell tritt es aber bei allen neu gemachten Rechnern auf. Ich werde wohl von einem der geht, das Image neu ziehen und dann weiterprobieren. Bootstick kann nicht die Lösung sein
Ja, alle Rechner identisch
Ja, alle Partitionen identisch
Jein, bei den Hardwareklassen: Startconf kopiert und Name ausgetauscht
nimm doch mal einen „problematischen“ in die Gruppe der
unproblematischen auf und partitioniere/synce ihn.
Nu um raus zu bekommen, ob es daran irgend wie liegt.
