Unraid verstellt BIOS Systemzeit?

Warum brauchst du denn im Bios eine lokale Zeit? Wegen dem Aufwecken?

Im Bios wird von Unraid die utc Zeit gespeichert. Und da wir nach der Zeitumstellung jetzt utc+2 sind, rechnet er dann selbst 2 Stunden drauf.

Hallo,
Ich habe das selbe Problem. Ich starte meinen Unraid Server per Bios.
Heißt dass ich nach jeder Zeitumstellung manuell die Bios Uhrzeit anpassen soll.
Meine HWClock zeigt mir die Systemzeit von Unraid an. Diese beziehe ich von einem NTP Server.

Gibt es mittlerweile schon eine Lösung für dieses Problem?

Gruß Tom.

Hi.

Das Problem gibt es bei "normalem" Linux auch, zumindest wenn man es im Dual Boot mit Windows auf demselben Rechner verwendet. Linux arbeitet mit UTC, Windows mit der lokalen Zeit ME(S)Z. Sind bei uns 1 (Winter) oder 2 (Sommer) Stunden Unterschied. Meine Linux Desktop Installation konnte ich mit einem kleinen Skript umstellen, so das sich nicht jedes mal, wenn ich das OS wechsele, die Uhrzeit verstellt. Ich hab es aber grade nicht griffbereit. War seinerzeit aber leicht zu ergooglen.

Ich persönlich bevorzuge das Windows Verhalten, da in der "echten" Welt nun mal die lokale Zeit gültig ist und nicht UTC. Damit würde es den Versatz bei der Zeitumstellung nicht (oder maximal für einen Tag) geben. Deswegen habe ich Linux auf das Windows Verhalten umgestrickt und nicht Windows auf das Linux Verhalten. Geht aber afaik beides. Ich denke, das könnte auch dieses Problem bei Unraid lösen.

Das Verhalten alternativer Betriebssysteme an das von Windows anzupassen ist kein guter Ansatz. Spätestens bei der nächsten Zeitumstellung verstellt das Windows die Hardwareuhr. Sollte eine 2. Windowsinstallation vorhanden sein und wird danach hochgefahren, macht diese es ein weiteres Mal. Ein dahingehend manipulierte Linux-Installation ebenso. Es ist sinnvoller den von Linux vorgeschlagenen Standard: UTC zu verwenden, dann ist keine Manipulation der Hardwareuhr notwendig, außer sie geht wirklich mal vor/nach.

Manchmal kaschiert ein erreichbarer NTP Server die doppelte Verstellung durch Dual-Boot, aber oft geht das auch schief. Beispiel ntpd: Zeitserver die mehr als 1000 Sekunden von der eigenen Uhrzeit abweichen werden als ungültige Zeitquelle deklariert und verworfen. Dadurch bleibt eine völlig falsch gestellte Uhr auch unkorrigiert.

Unsere Zeitzone inkl. Sommerzeitumstellung ist nur eine datumsabhängige Addition zu UTC. Das bekommt jedes vernünftige Betriebssystem von allein hin, es muss nur wissen, dass die HW-Clock (BIOS/UEFI) auf UTC läuft und unterlässt dann unnötige Manipulationen. Selbst Windows beherrscht das seit einigen Generationen, man muss es nur einmalig per Windows-Registry setzen und die Hardwareuhr im BIOS/UEFI auf UTC stellen:

Windowspage - Datum und Uhrzeit - BIOS/CMOS-Zeit als UTC-Zeit festlegen

Stellt man seine Windowsinstallation so ein, ist auch Dual/Multi-Boot völlig problemfrei bei jedweder Zeitumstellung.

Den einzigen Komfort den man dabei verliert, im BIOS/UEFI die Zeit in der lokalen Zeizone angezeigt zu bekommen. Aber selbst das könnte sogar vereinzelt schon funktionieren mit den ganzen lokalisierten graphischen UEFI-Oberflächen.

Zitat von HarryH

Es ist sinnvoller den von Linux vorgeschlagenen Standard: UTC zu verwenden, dann ist keine Manipulation der Hardwareuhr notwendig, außer sie geht wirklich mal vor/nach.

Also das sehe ich ganz anders. Zum Einen stellt Windows oder auch Linux, nicht zweimal die Zeit um auf Sommerzeit (habe ich in den letzten 30 Jahre noch nie erlebt) und zum Anderen ist der UTC "Quatsch" für einen lokalen Computer einfach Unsinn. Dann kommen nämlich solche Probleme wie das vom TE beschriebene falsche Aufwachen, was man dann jedes Mal erst im Bios (besonders toll bei einem "Headless" System) umstellen muss. Bei uns gilt nun mal nicht die UTC Zeit, sondern ME(S)Z und sonst gar nichts. Kann ja jeder so halten wie er will, aber bei mir gibt es keine UTC Uhren, basta. Ich will die "echte" Zeit haben, nicht irgendeine willkürlich ausgewählte Zeitzone, die hier nicht passt. UTC macht vielleicht Sinn bei einem Server, der irgendwo auf der Welt steht und nur übers Internet erreichbar ist. Aber bei einem System, das bei mir zu Hause steht, im Leben nicht.

Zitat von HarryH

Manchmal kaschiert ein erreichbarer NTP Server die doppelte Verstellung durch Dual-Boot, aber oft geht das auch schief. Beispiel ntpd: Zeitserver die mehr als 1000 Sekunden von der eigenen Uhrzeit abweichen werden als ungültige Zeitquelle deklariert und verworfen.

Interessant. Ich habe das seit gefühlt Jahrzehnten nicht mehr gesehen auf einigen Dual-Boot-Installationen bei mir, dass Zeit Probleme macht. Wie du schreibst, korrigieren Zeitserver das für Nutzer praktisch unmerklich. Ich meinte immer das ginge über ntp/ntpd. Hatte dabei Suse, Redhat, fedora, ubuntu und vermutlich mehr Varianten, die alle keine Probleme machten bei Multi-Boot mit verschiedenen Versionen von Windows über die Jahre.

Zitat von Lehmden1

und zum Anderen ist der UTC "Quatsch" für einen lokalen Computer einfach Unsinn.

Da habe ich ein Deja Vu - noch einmal weise ich drauf hin: praktisch alle wichtigen Zeitfunktionen laufen über UTC-parallele Zeit - und das ist auch wichtig und richtig so. Auch lokale Computer kommunizieren international. Datumsstempel von Dateien in allen modernen Dateisystemen sind selbstverständlich UTC basiert (werden aber für die Darstellung an den Enduser auf lokale Zeit umgerechnet). Bei Windows auf Terminal-Servern oder sogenannten VDIs ist es üblich dass User aus verschiedenen Zeitzonen sich anmelden, und das als Desktop nutzen. Für die Anzeige wird die Zeit umgerechnet. Normale POSIX-normierte Funktionen basieren auf UTC, genauso wie die wichtigsten Zeitfunktionen in Programmiersprachen, die ich kenne (z.B. time()). Code, der mit lokaler Zeit arbeitet hat oft (subtile) Bugs. Es gibt eine Stunde im Jahr, die mit lokalen Zeitstempel zweimal vorkommt und der lokale Zeitstempel kann keine eindeutige Zeit definieren. Transaktionen mit DBs, viele APIs, praktisch alles UTC basiert. Zeitdifferenzen von lokalen Zeitstempeln sind schwer zu berechnen ohne Umrechnung auf "globale Zeit" (und die ist bei DST-Umstellung wie genannt nicht immer eindeutig).

Auch im Nerds-Universum sind beispielsweise EPG UTC basiert.

Aber jetzt gewähre ich dir wieder das letzte Wort ...

Lehmden1

Du kannst die logischen und technischen Zusammenhänge für Dich gern ausblenden / ignorieren. Es hält Dich niemand davon ab. Wenn Du Dich in Deinem Haushalt genauer umschaust, wirst Du noch viel mehr Geräte vorfinden die intern auf UTC gestellt sind - einfach weil es eine weltweit definierte/akzeptierte stabile Zeitangabe ist und genau dafür geschaffen wurde. https://de.wikipedia.org/wiki/Koordinierte_Weltzeit
Du hättest viel Spaß mit einem Smartphone oder anderem mobilen Gerät, wenn es kein UTC als Zeitbasis hätte.

Das Einschaltproblem mit Unraid (PS: NAS & Co. zählt zu den Servern) ist unabhängig von der MEZ/MESZ vs. UTC-Thematik, denn die 1h Versatz über Nacht kommt in beiden Fällen zum Tragen. Die Hardwareuhr ist ein simpler Zähler der weiterläuft und interessiert sich nicht für Zeitzonen/Daylight Besonderheiten. Das ist auch die Ursache weshalb ein parallel installiertes Windows oder Linux ein 2. Mal an der Hardwareuhr "herumspielt", sofern MEZ/MESZ in der HW-Clock eingestellt ist. Das zuerst nach der Zeitumstellung hochgefahrene Betriebssystem erkennt, dass eine Änderung um 1 h stattfinden muss und zeigt diese dem Nutzer auch korrekt. Es setzt sich einen Flag im Dateisystem/Windows-Registry, dass dieser Wechsel stattgefunden hat und schreibt beim Herunterfahren die lokale Zeit in die Hardware-Clock. Das Problem: Im BIOS/UEFI wird der Daylight-Flag nicht hinterlegt. Das Betriebssystem welches danach gestartet wird und nicht dem ersten entspricht, weiß von der schon erfolgten 1h-Korrektur in der Hardware-Clock nichts und versucht es für sich erneut und vermerkt dies in den eigenen Betriebsystem-Einstellungen. Das Spiel geht solange, bist Du mit allen installierten Betriebssystemen 1x herum bist.

Wie schon erwähnt, das einzige was das durchaus kaschieren kann, ist ein einmalige erfolgreicher Abgleich mit einem NTP Server (übrigens mit UTC als Basis) direkt beim Hochfahren kurz nach der 1h Korrektur des Betriebssystems. Betreibt man z.B. noch ein älteres Windows wie XP o. Windows 7 ohne aktiven Netzwerkzugriff, gibt es keinen korrigierenden NTP Server und das Windows erkennt nur "Ah, da war doch Zeitumstellung seit dem letzten Hochfahren, also stell ich mal die Uhr um." Es weiß nichts davon, dass vorher die parallel existierende Windows 10/11 Installation das schon erledigt hatte!
Mit UTC als Basis in der Hardware-Clock passiert das nicht. Die Betriebssystem fahren genauso hoch wie bei lokaler Zeit in der Hardware-Clock, stellen dann aber nicht mehr an der Hardware-Clock herum, sondern "präsentieren" dem Nutzer die Uhrzeit immer korrekt mit der Differenz passend zur eingestellten Zeitzone.

Technisch richtig wäre in der genannten Konstellation des TE beim Herunterfahren zu prüfen ob der nächste Aufwachtermin nach einer Zeitumstellung liegt oder nicht.

• liegt der nächste Aufwachzeitpunkt nach einer Zeitumstellung, dann Aufwachzeit korrigieren
• liegt er davor, keine Änderung

Es gibt kommerzielle Produkte die sowas beachten und beherrschen, wäre die Frage ob es für Unraid ein ähnliches Skript für den vielfältigen BIOS/UEFI-Jungle gibt.

buers ,

eventuell hast Du das Zünglein an der Waage schon herausgelesen. Ob der Fehler/Vorgang für den Anwender "spürbar" (sofort sichtbar) auftritt hängt von ein paar Randbedingungen ab.

• Ist man restriktiv unterwegs und erlaubt dem alten Windows keinen Netzwerkzugriff, tritt es zu 100% auf
• startet man Windows zuerst nach der Zeitumstellung und Linux erst danach, aktualisiert der Zeitsynchronisierungsdienst im Linux die Zeit bevor die graphische Anzeige dem Nutzer ersichtlich wird, in den Logs sollte man den erneuten Zeitsprung dennoch sehen.
• startet man Linux zuerst, hängt es davon ab wie schnell Windows den Kontakt zum Zeitserver sucht und ab wann der Netzwerkzugang (WiFi) besteht um die falsche Uhrzeit zu korrigieren. Schaltet man den PC ein und geht noch schnell eine Kaffee holen o.ä. kann das in der Zwischenzeit schon erfolgt sein. In den Windows Systemlogs sollte der erneute Zeitsprung aber ebenfalls zu finden sein.
• Sind alle Betriebssystem auf UTC eingestellt, sollte im Idealfall keines der Bootlogs/Systemlogs Zeitsprünge aufweisen. Außer man hat genau im fraglichen Zeitfenster 2 - 3 Uhr den PC an bzw. in diesem Moment hochgefahren.

ntpd ist bei vielen Distribution schon lange durch Alternativen (chrony, systemd-timesyncd o.ä.) ersetzt worden. Diese haben meines Wissens nach dieses 1000 Sekunden Limit nicht bzw. synchronisieren hart 1x beim Servicestart. Dies wurde besonders wichtig für Geräte wie Raspberry Pi die ab Werk keine Echtzeituhr besitzen. Damit man dort brauchbare Bootlogs generieren kann, bedient man sich meist eines Tricks und schreibt den aktuellen Zeitstempel beim Herunterfahren in eine Datei. Beim nächsten Systemstart wird diese Zeit als Basis genommen, ansonsten das Build-Datum des OS oder 01-01-1970. Bei einem Herunterfahren länger als 20min. würde die Zeit immer zu weit weg für ntpd sein und das Uhrstellen grundlegend verhindern.

Zitat von HarryH

ntpd ist bei vielen Distribution schon lange durch Alternativen (chrony, systemd-timesyncd o.ä.) ersetzt worden.

EDIT OOmatrixOO - mögliche Lösung (falls noch benötigt) ganz unten.

Ok, das erklärt es dann. Ich war halt wegen deiner Aussage zu den 1000 Sekunden verwundert - ist ja bei uns immer überschritten bei "normalem" WIndows-Linux-Multiboot.

Ich hatte vor längerer Zeit schon Mal die Logs in Windows und Linux genau geprüft, Zeitkorrektur war immer schnell nach "Fremd-Boot".

Klar, programmierte Real-Time-Clock (RTC) Events, die den Rechner starten sollen (nicht aufwecken aus S3 oder S4) machen in Multi-Boot Probleme. In Hacker-/Nerds-Konfig kriegt man das aber auch pragmatisch in den Griff. Man wird RTC nutzen in einem "Hauptsystem", das man eh öfters nutzt und das per Default ohne weitere Interaktion bootet. Wenn man fremd bootet, muss man noch einen Leer-Boot/Shutdown (z.B. durch Skript) im Hauptsystem machen. (Oder man verzichtet auf Timer im S5 und stellt auf S4 um, was auch praktisch kaum Energie braucht). Ich fürchte allerdings, dass all die Erkenntnis dem OP nicht wirklich hilft. EDIT - mir fällt grade ein, dass RTC Wakeups vermutlich nicht funktionieren in Windows.

Ja, bei nicht vernetzten Geräten hat man ein Problem. Denke mir (Spekulation) dass das halt in Windows für immer von (nicht vernetztem) DOS geerbt wurde und dem alten BIOS Time Interrupt. Was Windows früh aus der BIOS-Zeit machen wird, ist einen UTC-basierten Timer zu initialisieren (vermutlich den 100ns Timer, der auf 1601-01-01 00:00:00 UTC beruht - sehr viele Windows APIs nutzen diesen Zeitstempel).

Ich frage mich, wieso die BIOS-Zeit (die ja nicht eindeutig bzgl. Zeitzone zu identifizieren ist) nicht durch was moderneres ergänzt wurde, das keinen Interpretations-Spielraum zulässt und von den OS zur Bootzeit genutzt werden kann. BIOS hat sich ja ansonsten auch weiterentwickelt. Damit sollte auch "täglich um 8:00 lokaler Zeit wecken" funktionieren.

Wenn ich dran denke, versuche ich mal ein RTC Wakeup in Linux direkt nach Ende der Sommerzeit. Bin zuversichtlich, dass das korrekt funktioniert. Vielleicht muss ich bisschen üben, mit den rtcwake Optionen.

OOmatrixOO , nach all der Diskussion könnte folgendes für dich funktionieren: BIOS Zeit auf UTC umstellen. AUfwecktimer im BIOS löschen, auf OS-Ebene das rtcwake Kommando nehmen, um Booten zu programmieren wenn es nächstes Mal 08:00 ist. rtcwake -m off ... könnte zum Testen hilfreich sein. Skripting mit Zeit/Datum ist nicht ganz trivial. Kann die bei Interesse und Bedarf sicherlich auch bei geholfen werden.

buers ,

für den genannten Einsatzzweck von OOmatrixOO bzw. tom06_09 , bietet sich auch noch nvram-wakeup an, sofern rtcwake als Nachfolger das nicht sowieso per ACPI schon abbildet. Kommt anscheinend aus dem VDR Projekt und ist genau dafür gemacht.

In anderen Fällen (z.B. Firmen) löst man sowas auch pragmatisch: Im eigentlichen Sinne geht es ja darum Serverdienste (Unraid) zu einem bestimmten Zeitpunkt zur Verfügung zu stellen.

Wenn man z.B. ganzjährig erreichen will: Fileserver erreichbar ab 08:00 lokaler Zeit, hinterlegt man im BIOS/UEFI 05:50 UTC als Einschaltmoment. Außerhalb der Sommerzeit würde Unraid schon ab 06:50 Uhr einschalten, aber der eigentliche Zweck wäre erfüllt. Ob jetzt die 1 Stunde zusätzlicher Stromverbrauch/Verschleiß den restlichen Aufwand rechtfertigt, muss jeder selbst für sich entscheiden. Für das Herunterfahren kann man das nach dem gleichen Muster handhaben, falls es keinen flexiblen Trigger/Timer dafür gibt.

HarryH Vielen Dank fuer die Erklaerungen. Ich hatte bisher auch bloss immer im Linux gesagt, das es Windows Zeit in der CMOS Uhr annehmen muss, aber mich nie gefragt, was da bei DST passiert.

Wieder mal ein typisches Window Design. Und 30 Jahre lang zu feige, den default zu fixen. Oder selbst den Fix kundenfreundlich in die System Settings reinzutun. Typisch Windows. Dabei haette man ja auch bei Einfuehrung von UEFI das Problem leicht loesen koennen durch passende UEFI Anforderungen.

Und natuerlich wieder so eine krasse Sollbruchstelle, weil das Problem kaschiert wird, wenn das Internet laeuft. Damit auch das Chaos zuhause maximal gross ist, wenn es denn mal nicht laufen sollte.