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.
gute Idee … werde ich machen, sobald ich die restlichen 5 per Hand reanimiert hab.
Aktuell ist wichtig, dass morgen alles läuft - dann kommen experimente
Die Gruppen heißen:
its1 ok
its2 ok
its3 ok
----------- nach denen kam gestern der Einbruch
gisela nicht ok
fsa nicht ok
… diverse
Zusatzfrage:
Ich habe zwei Gruppen, für die keine grub.cfg erstellt werden. Da mach ich ein neues Thema auf.
Gruppe Schüler PCs in der WebUI kopieren und neuen Namen vergeben
Lehrer PC in der WebUI aufnehmen in der neuen Gruppe mit identischem
Cloop
Lehrer PC partitionieren, klonen, Neustart, Bluescreen
Was funktioniert:
Lehrer PC in der Gruppe der Schüler PCs aufnehmen mit identischem Cloop
Lehrer PC partitionieren, klonen, alles ok
Lehrer PC in der WebUI in die Gruppe Lehrer PC verschieben, neues
Cloop erstellen und der Hardwareklasse zuordnen
Warum ist das so?
ich nehme an, weil beim „kaputten“ Weg der REchner mit linbo und der
„neuen“ start.conf partitioniert wird und bei m „zweiten“ Weg der
Rechner mit der „orginal“ start.conf partitioniert wird.
Unterscheiden sich die Partitionsgrößen?
Verscuh doch mal folgendes (Annahme, dass die Hardwareklassen .schueler
und .lehrer heißen).
Kopier auf dem Server die start.conf.schueler auf die start.conf.lehrer
(diese vorher wegsichern) und efitier dann in der start.conf.lehrer
deine Änderungen rein (nicht an den Partitionsgrößen schrauben!).
Danach linuxmuster-import-devices
und dann einen Rechner mit linbo partitionieren und syncen
root@server:/srv/linbo# diff start.conf.win10_r16s start.conf.win10_r16t
< Group = win10_r16s
---
> Group = win10_r16t
Verscuh doch mal folgendes (Annahme, dass die Hardwareklassen .schueler
und .lehrer heißen).
Kopier auf dem Server die start.conf.schueler auf die start.conf.lehrer
(diese vorher wegsichern) und efitier dann in der start.conf.lehrer
deine Änderungen rein (nicht an den Partitionsgrößen schrauben!).
Danach linuxmuster-import-devices
und dann einen Rechner mit linbo partitionieren und syncen
Ich versuch das bei der nächsten Gruppe/Imaging mal aus, das so zu machen bzw. komplett über die Konsole und nicht die WebUI.
wird wohl nicht viel bringen, denn ich hab alles auf der Shell gemacht.
Start.conf kopiert und nur den Gruppennamen geändert => bluescreen.
Ich bekomme beim Diff auch nur den Unterschied beim Gruppennamen angezeigt.
(Muss nichts heißen, vll. funktioniert es in einem anderen Netz ja so …)
wie sind den die Rechte der start.conf.lehrer Datei?
Wurde nach dem Kopieren der start.conf.schueler auf die
start.conf.lehrer ein linuxmuster-import-devices gemacht?
Normalerweise sichert linbo beim Erstellen eines Images den bootcode von
windows in eine Datei auf den server und spielt diesen beim Imagen zurück.
Es sieht so aus, als würde es das in der anderen Gruppe nicht machen…
was seltsam ist, weil ich genau sowas schon etliche Male gemacht habe
(vorhandenes image einer frisch erstellten Gruppe zusätzlich zu geordnet).
das ist immer noch ein Thema welches offen ist. Heute bin ich auch wieder drüber gestolpert.
Eine Harwareklasse mit SATA, eine mit NVME, selbes Image.
Klone ich das SATA Image mit Clonezilla auf den NVME Laptop, so bootet dieser ohne Probleme.
Klone ich dagegen mit linuxmuster, bekomme ich den besagten Bluescreen. start.conf ist identisch von den Partitionsgrößen. Unterschied sind nur die Partitionsbezeichnungen.
Wie funktioniert überhaupt das Imaging mit linuxmuster.net. Offenbar macht partclone/Clonezilla da etwas anderes. Scheint so, als ob es hier noch einen Fehler gibt.
