ich habe hier mit 2 IT-Räumen und Terra PCs ein seltsames Problem.
Die PCs klonen ohne Probleme mit Linbo. Die Bootreihenfolge steht danach dann auf:
grub
IPv4
IPv6
Windows Bootmanager
Nun booten die PCs an einem Tag alle komplett ohne Probleme von grub und dieser startet dann Linbo und das dann Windows 10. Von einem Tag auf den anderen ist dann entweder der grub zerschossen, oder Windows endet im Bluescreen.
Aber nicht bei allen PCs.
Die PCs wurden auch korrekt runtergefahren. Das BIOS ist Up-to-Date von 2019.
Ein Linbo sync bringt nichts. Nur bei format,partition,sync startet der PC dann wieder.
Ich bin mit meinem Latein am Ende und hoffe auf Unterstützung. Danke!
Viele Grüße
Klaus
# start.conf.win10_itraum_sata
[LINBO]
Server = 10.0.0.1
Group = win10_itraum_sata
Cache = /dev/sda4
RootTimeout = 600
AutoPartition = no
AutoFormat = no
AutoInitCache = no
DownloadType = torrent
BackgroundFontColor = white
ConsoleFontColorStdout = lightgreen
ConsoleFontColorStderr = orange
SystemType = efi64
KernelOptions = quiet splash
[Partition]
Dev = /dev/sda1
Label = efi
Size = 200M
Id = ef
FSType = vfat
Bootable = yes
[Partition]
Dev = /dev/sda2
Label = msr
Size = 128M
Id = 0c01
FSType =
Bootable = no
[Partition]
Dev = /dev/sda3
Label = windows
Size = 50G
Id = 7
FSType = ntfs
Bootable = no
[Partition]
Dev = /dev/sda4
Label = cache
Size = 50G
Id = 83
FSType = ext4
Bootable = no
[OS]
Name = Windows 10
Version = 20H2
Description = Windows 10 20H2
IconName = win10.png
Image =
BaseImage = win10-20H2-SATA-s.cloop
Boot = /dev/sda3
Root = /dev/sda3
Kernel = auto
Initrd =
Append =
StartEnabled = yes
SyncEnabled = no
NewEnabled = yes
Autostart = yes
AutostartTimeout = 5
DefaultAction = start
RestoreOpsiState = no
ForceOpsiSetup =
Hidden = yes
… das meinst du: das ist aber vom normalen Nutzer weder zu beurteilen noch zu bearbeiten.
Wurde der global.reg korrekt eingespielt?
Der deaktiviert den hybriden Ruhezustand von Windows.
„neu starten“ ist nämlich sonst die einzige Methode um „wirklich herunter zu fahren“. Herunterfahren versetzt Windows nur in einen Schlafzustand.
Dann ist es wichtig, dass man das BIOS Passwortschützt und die Einstellungen gegen Manipulation sichert (das ist bei meinen Lenovos eine BIOS Einstellung, dass das Betriebsystem nix mehr ändern kann).
Nur so kann man Bootreihenfolgemanipulationen durch Windows verhindern.
danke für Deine schnelle Rückmeldung und die Hinweise.
Bzgl. Bootreihenfolge und UEFI habe ich bei den Rechnern festgestellt, daß es irrelevant ist, ob ein BIOS Kennwort gesetzt ist, oder nicht.
Hiberboot ist deaktiviert. win10.global.reg wurde ausgeführt.
hat hier noch jemand eine Idee was da falsch ist?
Die PCs laufen ein paar Tage und dann wieder Bluescreen. Auch die welche ich schon neu partitioniert/gesyncht hatte.
sag mal ein paar Dinge zu den Rechnern.
Sind es immer die gleichen?
Wie viele sind betroffen?
Sind die alle mit gleicher Hardware?
Sind alle dieser Hardware betroffen?
Gibt es Rechner mit dem gleichen Image aber anderer Hardware und sind die betroffen?
Sind nur Rechner in einem Raum betroffen?
das sind alles identische Terra PCs mit SSD in 2 IT Räumen mit aktuellstem BIOS von 2019. Eingestellt auf UEFI Boot. Dabei sind immer unterschiedliche Rechner betroffen. Wenn die Rechner dann repariert wurden(format, partition, sync) laufen sie eine Zeit bis das dann wieder passiert.
Das Windows 10 20H2 Image kommt ursprünglich von einem NVME Acer PC, auf denen das nicht passiert.
Das NVME Image wurde damals auf den Terra geklont und mit der Windows Boot DVD repariert, so daß es auf den Terra PCs lauffähig wurde. Anschließend ein neues Image erstellt. Kann das der Grund sein? Aber wieso läuft es dann eine zeitlang?
das hilft schon mal um ein „Gefühl“ zu bekommen (ich arbeite viel mit Gefühl … klingt komisch … hat sich bei mir aber bewährt).
Lass uns das noch ein wenig ausweiten:
Zwei Räume: wieviele Rechner sind da zusammen drin?
Wieviele sind den „pro Woche“ oder so, betroffen?
Gibt es Rechner die nie betroffen waren? (Lehrerrechner oder der hinten links…).
Wie werden den die Rechner gestartet?
Automatisch?
„Von Hand“?
Wie ist das Startverhalten eingestellt?
Immer sync? Immer neu? immer Start?
Hast du nach der bootreparatur auch mal ein windows update durchgeführt, damit Windows die korrekten Treiber für die Terras hat?
Hast du die Windowsupdates richtig tot gemacht? (das geht unter 20H2 nur mit einem spezialprogramm)?
danke fürs Nachhaken! Ein Gefühl bei IT-Problemen ist absolut notwendig um Fehler eingrenzen zu können und vor allem um nicht sofort nachvollziehbaren Problemen näher zu kommen
Nun zu Deinen Fragen:
Pro Woche sind ca. 3-5 PCs von insgesamt 38 PCs betroffen. Es betrifft immer wieder neue, aber auch alte PCs, eine Regel kann ich nicht feststellen. Gestern dummerweise erstmals auch der Lehrer PC.
Die Rechner werden händisch gestartet.
Startverhalten, siehe oben die start.conf. Immer „Start“.
Die Hardware wurde korrekt erkannt, bzw. Treiber nachinstalliert. Die einzige Änderung die ich manuell machte war die Grafikkarte, da der Windows Standard Grafiktreiber, statt dem Intel Treiber installiert war.
Die Windowsupdates habe ich geblockt, indem ich in den Eigenschaften der Ethernetverbindung in Windows 10, diese auf „Getaktete Verbindung“ gestellt hatte. Ich habe gerade einen virtuellen PC mit dem Image bestückt und da war die getaktete Verbindung aus. Kann aber sein, daß das deshalb so ist, weil die Netzwerkkarte eine andere ist als in den Terras. Das muß ich also nächste Woche vor Ort nochmal kontrollieren. Danke für den Hinweis, könnte gut sein, dass es was damit zu tun hat.
ich würde sicher stellen, dass man die Windows Kisten nicht syncen kann (also
sync = no in der start,conf).
Dann kann man immer noch „Neu und start“ machen, was oft eh schneller ist.
Meine Windowskisten stehen immer auf neu+start als Default beim booten (man hätte 3 Sekunden zeit um „start“ zu wählen) und sie werden an Schultagen (Dank dem Script von Jesko) Morgends um 7:20 Uhr gestartet per Wake on Lan: dann ist die Synczeit egal.
Dass ich Windows nur gesynct starte liegt daran, dass ich Windows weder für sicher genug noch für robust genug halte um das anders machen zu wollen.
Außerdem läuft einem so auch nicht die Partition voll, was auch Nebenwirkungen hat und ein Chaotisches Auftreten bei dir erklären könnte (aber dann gäbe es das auch in den anderen Räumen … nehme ich an).
Wegen der updates empfehle ich das updateblockerprogramm über das wir letztes Jahr hier geredet haben (irgend wo im Forum)
„SyncEnabled = no“ habe ich bereits in der start.conf.
Der Tip mit neu+start als default hatte ich in einer Schule auch. Da gab es dann bei Laptops das Problem, daß irgendwann die Vertrauensstellung zur Domäne verlorengegangen ist, wenn der Laptop nur mit WLAN und nicht LAN verbunden war. Ebenso schwierig ist, daß man bei neu+start, dann Microsoft Office dann wieder aktivieren muß. Ansonsten eine gute Idee mit der Automatisierung von neu+start.
Die Windows Updates mit Squid ACLs zu blockieren funktioniert gut, füllt aber auch die Logs der OPNsense. Ich habe das jetzt kontrolliert und gesehen, daß die MS Updateserver in einer Whitelist stehen. Ich kann mich erinneren, daß ich das aktiviert habe, da sonst die Windows 10 Aktivierung nicht geklappt hatte. Offenbar habe ich das nach der Aktivierung vergessen rückgängig zu machen. Da wurde also nichts blockiert und es könnte gut sein, daß Windows Updates die Ursache für das Problem sind.
Danke für den Tip mit dem „Windows Update Blocker“ - probier ich aus.
so, heute bin ich evtl. etwas weiter mit meinem Problem.
Ich habe festgestellt, daß die Partitionstabellen der PCs Probleme haben:
root@server.linuxmuster.lan@mjs:~# linbo-ssh r26-pc02
Warning: Permanently added '[r26-pc02]:2222' (RSA) to the list of known hosts.
~ # gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.3
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.
Warning! One or more CRCs don't match. You should repair the disk!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Command (? for help): v
Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.
Problem: main header's disk GUID (3AC221F3-DCE3-467A-A5A6-4D3D2802D359) doesn't
match the backup GPT header's disk GUID (77881878-1F2B-4F80-A617-E2086D56060D)
You should use the 'b' or 'd' option on the recovery & transformation menu to
select one or the other header.
Identified 2 problems!
Nun habe ich folgendes gemacht:
Image zurückspielen
Partitionstabelle mit gdisk reparieren
PC neu starten. Mit linbo-ssh und gdisk Partitionstabelle überprüft: Keine Fehler
Neues Image erstellt
Anderen PC formatiert, partitioniert, sync mit dem neuen Image
Neustart und wieder dieselben Partitionsfehler.
Auch mit einer anderen, größeren SSD probiert.
Offenbar schreibt Linbo die Partitionstabelle nicht richtig?
eine efi start.con.
Ist den sicher gestellt, dass der Client per EFI von der Netzwerkkarte bootet?
Da haben BIOSe manchmal ganz seltsame Ansichten…
Glück hat man, wenn sie direkt dazu schreiben, was sie machen: also PXE zweimal auftaucht, einmal mit UEFI dahinter …
Aber ich glaube nicht, dass es daran liegt. Das schreib ich nur, dass du ein Auge drauf hast.
Zuerst mal stört das protected MBR Schema, dass da noch vor liegt: im efi Modus wird GPT verwendet.
Das kann Windows durcheinander bringen beim booten.
Also mach mal folgendes: lösch die Festplatte (alle Partitionen) und erstell eine leere GPT Tabelle. Dann sollte das MBR Zeug weg sein.
Dann linbo booten und nochmal partitionieren: findet fdisk danach immer noch Fehler?
Wenn nein: clonen.
Wenn Windows dann immer noch mit BlueScreen bootet, dann reparieren wir das so:
von Windows CD/USBstick booten
Reparaturoptionen → erweitert → Eingabeaufforderung
(Die Startdateireparatur kannst du ignorieren: die macht schon lange nix Sinnvolles mehr).
in der Eingabeaufforderung folgende eingeben:
c:
bootrec /fixboot
bootrec /rebuildbcd
rebooten und Windows starten (ohne sync)
wenn das klappt: reboot und Image erstellen.
bootrec /fixboot
macht auch mal gerne nix und sagt „Zugriff verweigert“
Einfach ignorieren.
Ich hab erst Heute so eine Windwosinstallation repariert, die nicht mehr booten wollte, nachdem ich die 80GB Platte gegen eine 120GB Platte getauscht habe … wie Wege des Windwos sind unergründlich…
Es ist ja so, daß der Bluescreen nur manchmal nach einiger Zeit auftaucht.
Die start.conf wurde aus dem Template von Linbo erstellt, also über die WebUI.
Ich habe mit Linbo formatiert und partitioniert und dann wird die Partitionstabelle mit dem protected MBR Schema so angelegt. Bei einem direkt darauffolgenden Test wird mit gdisk kein Fehler gefunden. Wird das Image allerdings dann zurückgespielt findet gdisk dann diese genannten Fehler. Das kann ich mit gdisk durchaus reparieren, dann ein neues Image erstellen. Beim zurückspielen ist der Fehler dann wieder da. Die PCs booten trotzdem, aber eben nur eine gewisse Zeit. Deshalb vermute ich Linbo als die Fehlerquelle.
Könnte bitte jemand mal mit linbo-remote auf einen PC und mit „gdisk /dev/sda“ oder „gdisk /dev/nvme0n1“ und dann „v“ wie „verify“ nachsehen, ob es da auch Fehler gibt?
Gerade nochmal in einer virtuellen Maschine das Image eingespielt. Hier ein anderer gdisk Fehler:
root@server.linuxmuster.lan@mjs:~# linbo-ssh win10-master
~ # gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.3
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): v
Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.
Identified 1 problems!
Command (? for help):
die beiden Fehlermeldungen im ersten Beitrag sagen eindeutig, dass die BCD Datei in der EFI-Partition fehlt oder beschädigt ist. Wenn der Fehler wieder auftritt, dann solltest du mal schauen, ob die Dateien vorhanden sind und mit einem funktionierenden System vergleichen. Vielleicht kann man so feststellen, was da kaputt geht und wieso.
Da das Windows von einem Acer PC mit NVME kommt, solltest du auch nochmals prüfen, ob die Treiber passen. Das geht für Intel Systeme gut mit Intel® Treiber- und Support-Assistent.
Auf jeden Fall schau mal, welcher Treiber für die SSD verwendet wird.
Ein paar Daten über das ursprüngliche System und den Terra-PC wären auch gut.
danke für den Tip mit dem Treiber für den Controller/SSD und den Link!
Ebenso werde ich die EFI Partition eines funktionierenden mit einem defekten PC vergleichen.
Im Moment habe ich die UEFI Bootreihenfolge auf Windows zuerst eingestellt ein BIOS Kennwort gesetzt und den „Windows Update Blocker“, den Holger empfohlen hatte, installiert. Mal sehen, wie sich das mit der Zeit verhält.
