Mal wieder ein interessanter PC-Fehler: nach kurzem Tastendruck auf den "PWR-BTN" zum Herunterfahren machte mein Rechner gestern abend einen auf hart-aus. So wie wenn man hinten den Kippschalter schaltet oder eben den Stecker zieht. beim nächsten Wiedereinschalten lädt Windows nicht mehr richtig: "failed - a required device is missing" Hardware konnte ich ausschliessen, mit einem live-Ubuntu war alles da, alle Daten zugänlich. OK, Windows-DVD und "reparieren": es sucht sich nach einem installierten Windows tot, nach einer halben Stunde dann gefunden. auf "reparieren" geklickt kommt die Meldung "kann nicht". geklonte Platte angeschlossen - genau das selbe. letzter Ratschluss = BIOS blöd? nach Reset funzt alles wieder normal. sorry wenn ich schreie, aber: WAS ZUM GEIER VERSTELLT MIR DAS BIOS ??
Spendier dem Board mal eine neue CR2032 Batterie.
nach'm halben Jahr? wären bei einer leeren Batterie nicht auch Zeit/Datum blöd?
Gast
#4854933
Kannst mal nachmessen, ob die 5VSB noch stimmen und ripplefrei sind.
● J-A V. schrieb: > wären bei einer leeren Batterie nicht auch Zeit/Datum blöd? Nicht unbedingt. Die Fehler, die bei einer beinahe leeren CMOS-Batterie auftreten, variieren extrem. Wenn die RTC noch läuft und ständig die Uhrzeitfelder auffrischt... Wenn der PC an einer Steckdosenleiste hängt und das Board scheiße entworfen ist, versorgt die CMOS-Batterie eventuell noch andere Schaltkreise und ist schneller leer. Oder die Batterie war schon neu ein billiges Lagerkind... Eine weitere Möglichkeit ist, dass du dir schlicht einen Virus gefangen hast, der auch auf der geklonten Platte drauf ist und allen möglichen Murks macht. Linux ist dann naturgemäß nicht betroffen. Als die Sasser-/Blasterwellen unter XP liefen, wurden die Systeme reihenweise schon während der Installation infiziert...
S. R. schrieb: > ● J-A V. schrieb: >> wären bei einer leeren Batterie nicht auch Zeit/Datum blöd? > > Nicht unbedingt. Die Fehler, die bei einer beinahe leeren CMOS-Batterie > auftreten, variieren extrem. Wenn die RTC noch läuft und ständig die > Uhrzeitfelder auffrischt... Im Gegensatz zu früher werden bei heutigen BIOSsen die Konfigurationsdaten nicht mehr in einem Battery-backed-CMOS-RAM gespeichert, sondern in einem speziellen Sektor des BIOS-Flashs. Die Batterie wird nur noch für die RTC und (wenn vorhanden) den Tamper-Switch verwendet. In manchen BIOSsen gibts noch nen "config reset"-Bit. Wenn die Spannung der Batterie zusammenbricht, wird das auch zurückgesetzt und beim nächsten Start setzt das BIOS dann den Config-Sektor im Flash zurück. Das wird vermutlich gemacht um das alte Verhalten mit dem Battery-backed-RAM zu emulieren. Da gibt es jetzt also keinen Fall mehr in dem nur ein Teil der Einstellungen erhalten bleibt oder verstellt wird.
Ich will Dir nun wirklich keine Angst machen, aber die aktuellen (U)EFI (also das, was wir in aktuellen Boards so als BIOS-Nachfolger haben) sind durchaus aus dem OS erreichbar. Und beschädigbar. https://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-directory Geht leider auch mit Windows, wie ich rausfinden durfte. Und angesichts dessen, dass das Sicherheitskonzept von Windows nur ein "all or nothing" vorsieht, kann im Prinzip jedes Programm das erhöhte Rechte einfordert mal eben lustig das Mainbaord zum Hühnerfutterersatzteillager machen. Nett, nich'?
Gast
#4857882
Heinz L. schrieb: > Ich will Dir nun wirklich keine Angst machen, aber die aktuellen (U)EFI > (also das, was wir in aktuellen Boards so als BIOS-Nachfolger haben) > sind durchaus aus dem OS erreichbar. Und beschädigbar. > > https://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-directory > > Geht leider auch mit Windows, wie ich rausfinden durfte. Und angesichts > dessen, dass das Sicherheitskonzept von Windows nur ein "all or nothing" > vorsieht, kann im Prinzip jedes Programm das erhöhte Rechte einfordert > mal eben lustig das Mainbaord zum Hühnerfutterersatzteillager machen. > > Nett, nich'? Das dies nur bei einem bestimmten Hersteller funktioniert, hast du aber weggelassen. Davon abgesehen war es auch eine blöde Idee die NVRAM Variablen in Linux R/W einzubinden...
Es war mir ehrlich gesagt nicht bewußt, dass dies nur mit einem Hersteller geht. Welcher wäre das? Soweit mir bisher bekannt geht dies mit jedem UEFI-Board. Und, wie gesagt, die Variablen sind auch in anderen Systemen erreichbar, so gesehen... wenn schon mal was OS-unabhängig funktioniert, warum kann's nicht was Nützliches sein...
Gast
#4858126
Hersteller müsste ich jetzt recherchieren. Das Problem war, es wurde eine Variable im NVRAM erzeugt, bei deren nicht vorhanden sein der Bootprozess gestoppt wurde bzw. abstürzte. Normalerweise kann man alle Variablen (z.B. SetupData) komplett löschen, das System bootet dann mit defaults und legt eine neue Variable mit den default Einstellungen an...
bei meinem alten XP-Rechner musste auch gelegentlich -ca alle 20 mal booten das BIOS aufgerufen werden. Nichts verstellen, sondern nur auf "save settings" gehen. "quit without saving" ging dabei nicht. Sonst wollte der auch nicht starten, blieb ohne Fehlermeldung mit blinkenden Cursor als einzige Anzeige einfach stehen. Das ging auch mit einer neuen BIOS-Batterie so.
Gast
#4858150
Nachtrag: war laut Bugreport ein MSI Notebook https://github.com/systemd/systemd/issues/2402
nach einem Ubuntu Update heute bleibt beim Rechnerstart die Num-Lock LED aus. hats hier also auch ins BIOS eingegriffen. warum lassen OS das BIOS nicht in Ruhe? Warum meint ein Entwickler dass ich jetzt das KP nicht zur Zifferneingabe nutzen soll??? Was also muss man dann noch am BIOS verändern, was nicht so auffällig ist?
Dir ist schon klar, dass die BIOS-Einstellung für Numlock seit Windows NT keine Rolle mehr spielt? Sowohl Windows NT als auch Linux setzen ihre eigenen Defaults beim Boot.
mir ist klar dass OS ins BIOS eingreifen. nur warum meint jemand irgendwo zu wissen, was ich für Einstellungen haben soll?
Gast
#4862845
● J-A V. schrieb: > mir ist klar dass OS ins BIOS eingreifen. In dem Fall greift es nicht ins BIOS ein. Es geht nur seinen eigenen Weg.
wie erreiche ich es, dass eine BIOS-Einstellung ausser durch eine leere Batterie nicht geändert wird, wenn ich es nicht möchte?
Die NumLock-Einstellung ist zwar eine BIOS-Einstellung, die aber von modernen Betriebssystemen (also Windows ab NT 3.1, Linux, OS/2) vollständig ignoriert wird. Daher bieten diese Betriebssysteme auch keine Möglichkeit an, diese Einstellung zu verändern. Damit basiert deine Folgefrage auf einer falschen Grundannahme es gilt der der Grundsatz "aus Falschem folgt Beliebiges". Die Antwort auf deine Frage lautet "gar nicht", denn was du willst, ist für dich nicht möglich. Das hilft dir aber auch nicht weiter.
gut, gehen wir mal davon aus dass dem so ist. Bleibt dann immer noch die Frage: Woher wird die (oder werden die) Einstellung(en) geändert, wenn ich die nicht getätigt habe? 's muss ja irgendwo her kommen.
Da sich BIOS-Einstellungen normalerweise nicht von alleine ändern, Defekte außen vor gelassen, glaube ich auch an die Annahme bei dieser Frage nicht.