Debian liest Hardware Zeit inkorrekt

[spiralnebelverdreher]

Aktuelle Bios-Zeit wie befürchtet ist auch 70 Stunden voraus:
und das selbe mit der Windows-Systemzeit

Wenn es jemand nicht glaubt, kann ich auch paar screenshots schicken.

Bios Zeit https://www.dropbox.com/s/v3e3vv4os853d ... 3.jpg?dl=0
Windowszeit https://www.dropbox.com/s/efcygr2a0pk5e ... 1.jpg?dl=0

Ich würde (auch wenn du das mit dem ntp Daemon hinkriegst und die Uhrzeit erstmal wieder korrekt aussieht) mal den Rechner aufschrauben und die BIOS Batterie wechseln. Sonst vergisst der irgendwann, welche Platte wo verbaut ist, von was er booten soll und dass der vielleicht ein Boot-Passwort hatte. Und die Jahreszahl wird dann evtl bei 1970 liegen.

[rendegast]

Anmerkung:
Windows übernimmt die RTC-Zeit als System-Zeit,
und W32Time kann diese im Rahmen der Max...PhaseCorrection korrigieren.
Aber Windows kann nicht an der RTC-Zeit herumdrehen, systembedingt
(gilt nach meinem Stand zumindest bis Windows7).
An der RTC-Zeit dreht danach nur linux.



Es gäbe ein BIOS Version 216 (2011-02) für K72DR
https://www.asus.com/support/Download/3 ... HfEv0De/8/
Beschreibung: "Firmware change" (?)

[micha81929]

Anmerkung:
Windows übernimmt die RTC-Zeit als System-Zeit,
und W32Time kann diese im Rahmen der Max...PhaseCorrection korrigieren.
Aber Windows kann nicht an der RTC-Zeit herumdrehen, systembedingt
(gilt nach meinem Stand zumindest bis Windows7).
An der RTC-Zeit dreht danach nur linux.

Ja, das entspricht genau meiner Beobachtung, Ich würde aber gerne auch "Linux" abgewöhnen, an der RTC Zeit herumzukorrigieren.

[NAB]

Soweit ich das inzwischen verstehe, ist mit der BIOS-Uhr alles in bester Ordnung und es ist die Systemuhr, die massiv vorgeht - aber nur unter Debian. Und Debian schreibt die falsche Systemzeit dann in die BIOS-Uhr.

micha81929, bist du mit dem System mal von einem Intel-Prozessor auf dieses AMD-System umgezogen? Und hast du das System selber installiert, oder hat das irgendwer anders gemacht?

Und kannst du im BIOS mal alles, was nach "PowerNow" oder "Cool'n'Quiet" klingt, testweise abschalten?

Und was sagt

Code: Alles auswählen

dmesg | grep clock

bei dir?

Hier:
https://www.kernel.org/doc/Documentatio ... meters.txt
findet du unter "clocksource" übrigens ein paar Kernelparameter, die du ausprobieren könntest. Damit kannst du einstellen, welchen Zeitgeber er für die Systemzeit nimmt, da gibt's nämlich mehrere Möglichkeiten. Soweit ich das sehe, kommen für dich in Frage:
jiffies, acpi_pm, pit, hpet, tsc

[guennid]

Helfen werde ich micha1929 nicht mehr, mir ist das zu ignorant.
Aber das Herumgestochere der übrigen Beteiligten wirft für mich eine neue Frage auf: Bisher ging ich davon aus, dass (nicht nur) Debian seine Systemzeit aus der hardware-Uhr holt und die auch nicht antastet, es sei denn, dass ich ihm explizit sage, es also bewusst so umkonfiguriere, dass es sie woanders herholen und dann die Hardware-Uhr danach stellen soll. Ist dem nicht mehr so?
Anders gesagt: Wird jetzt defaultmäßig ein Client, der die Zeit aus dem Netz holt, nicht nur installiert, sondern auch automatisch aktiviert, ohne das der User das mitkriegt?

Grüße, Günther

[dufty2]

wirft für mich eine neue Frage auf: Bisher ging ich davon aus, dass (nicht nur) Debian seine Systemzeit aus der hardware-Uhr holt und die auch nicht antastet, es sei denn, dass ich ihm explizit sage, es also bewusst so umkonfiguriere, dass es sie woanders herholen und dann die Hardware-Uhr danach stellen soll. Ist dem nicht mehr so?

Häh?
Kenne ich eingentlich nicht anders: Booten, auslesen der RTC, dann synchronisieren mit z. B. NTP,
beim Runterfahren setzen der RTC mit der (hoffentlich) nun genaueren Systemzeit.
Das Wiki von Arch ist da auch meiner Meinung:

RTC clock

Standard behavior of most operating systems is:

Set the system clock from the hardware clock on boot.
Keep accurate time of the system clock with an NTP daemon, see #Time synchronization.
Set the hardware clock from the system clock on shutdown.

Scheint auch zu passen:

Code: Alles auswählen

$ timedatectl 
      Local time: Wed 2016-06-08 16:44:16 CEST
  Universal time: Wed 2016-06-08 14:44:16 UTC
        RTC time: Wed 2016-06-08 14:44:16
       Time zone: Europe/Berlin (CEST, +0200)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

[guennid]

Es geht nicht darum , dass man's machen kann.
Ich mache das allenfalls bei Bedarf (Desktop) und ich musste dazu noch bei keiner Installation einen ntp-Dämon ausschalten.

Grüße, Günther

[dufty2]

Wenn Du bei Debian einen Daemon installierst (und das ist nicht nur bei Zeit-Daemonen so),
wird er auch gleich aktiviert.
Das stört mich etwas, denn z. B. bei OpenBSD ist das nicht der Fall.

[guennid]

Wenn Du bei Debian einen Daemon installierst (und das ist nicht nur bei Zeit-Daemonen so),
wird er auch gleich aktiviert.

Das ist doch auch nicht die Antwort. Wird er denn automatisch installiert und damit aktiviert?
Okay, dann habe ich keinen installiert. Auf meinem Debian-Router mache ich das so, wie von dir beschrieben, dh. der holt sich nach jedem Booten die Zeit aus dem Netz - aber das musste ich explizit so installieren/einrichten. Auf den Maschinen im LAN hole ich dann, wenn mir danach ist, die Zeit vom Router - per ntpdate aber da ist nix mit automatisch.

Und daran krankt doch hier der ganze thread - Er sagt ja nirgends, was denn nun Sache ist, auch dann nicht, wenn er's ankündigt. Dass die Bios-Uhr defekt ist, halte ich zumindest für um Längen wahrscheinlicher, als dass ntp sich irgendwoher irgendeine Mondzeit einfängt - jedenfalls habe ich sowas noch nicht gelesen. Nur müsste er dazu mal sagen, was denn die Bios-Uhr (bei Debian UND windows) sagt, statt blind mit irgendwelchen Drift-Zahlen um sich zu werfen.

[micha81929]

Und was sagt

Code: Alles auswählen

dmesg | grep clock

bei dir?

root@Michas-BigAsus:/home/michael# dmesg | grep clock
[ 0.000000] hpet clockevent registered
[ 0.243115] Switching to clocksource hpet
[ 0.676786] rtc_cmos 00:05: setting system clock to 2016-06-08 00:15:07 UTC (1465344907)
[ 1.620105] Refined TSC clocksource calibration: 2094.754 MHz.
[ 1.620118] Switching to clocksource tsc
root@Michas-BigAsus:/home/michael#

[micha81929]

Soweit ich das inzwischen verstehe, ist mit der BIOS-Uhr alles in bester Ordnung und es ist die Systemuhr, die massiv vorgeht - aber nur unter Debian. Und Debian schreibt die falsche Systemzeit dann in die BIOS-Uhr.

micha81929, bist du mit dem System mal von einem Intel-Prozessor auf dieses AMD-System umgezogen? Und hast du das System selber installiert, oder hat das irgendwer anders gemacht?

Und kannst du im BIOS mal alles, was nach "PowerNow" oder "Cool'n'Quiet" klingt, testweise abschalten?

Und was sagt

Code: Alles auswählen

dmesg | grep clock

bei dir?

Hier:
https://www.kernel.org/doc/Documentatio ... meters.txt
findet du unter "clocksource" übrigens ein paar Kernelparameter, die du ausprobieren könntest. Damit kannst du einstellen, welchen Zeitgeber er für die Systemzeit nimmt, da gibt's nämlich mehrere Möglichkeiten. Soweit ich das sehe, kommen für dich in Frage:
jiffies, acpi_pm, pit, hpet, tsc

Ich habe die 64bit Debian Gnome Wheezy version von einer 2015 von Debian aus dem Netz angefertigte ROM image installiert. Es war vorher nicht auf einer INTELPlatform, immer auf AMD.

Ich bin gerade wieder extrem enttäuscht, da ich gestern Nacht geglaubt hatte, das Problem identifiziert zu haben. In etc/default/hwclock.config gibt es im Prinzip die Möglichkeit, HWCLOCKACCESS auf NO zu setzen (was ich gemacht hatte).

# Defaults for the hwclock init script. See hwclock(5) and hwclock(8).

# This is used to specify that the hardware clock incapable of storing
# years outside the range of 1994-1999. Set to yes if the hardware is
# broken or no if working correctly.
#BADYEAR=no

# Set this to yes if it is possible to access the hardware clock,
# or no if it is not.
HWCLOCKACCESS=no

# Set this to any options you might need to give to hwclock, such
# as machine hardware clock type for Alphas.
#HWCLOCKPARS=

# Set this to the hardware clock device you want to use, it should
# probably match the CONFIG_RTC_HCTOSYS_DEVICE kernel config option.
#HCTOSYS_DEVICE=rtc0



Ich habe das System dann mit dieser Einstellung runtergefahren und wieder neu gebootet )nachdem ich BIOS-Zeit und Systemzeit auf die tatsächlichen Werte manuell korrigiert hatte).
Leider steht jetzt gerade trotzdem die Systemzeit und die Bioszeit wieder fast 3 Tage in der Zukunft:

root@Michas-BigAsus:/home/michael# date
Sa 11. Jun 15:23:46 CEST 2016
root@Michas-BigAsus:/home/michael# hwclock -D
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1465337519 seconds after 1969
Last calibration done at 1465337519 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
hwclock: select() to /dev/rtc to wait for clock tick timed out: Success
...synchronization failed
root@Michas-BigAsus:/home/michael#

etc/adjtime zeigt immer noch die 11 h Differerenz zwischen Systemzeit und BIOS-Zeit.

Ich werde jetzt nochmal die adjtime Differenz auf 0 setzen, und HWCLOCKACCES=NO lassen. vielleicht bringt das ja etwas.

PS: Obwohl einige Forumteilnehmer schon etwas genervt scheinen, möchte ich doch an dieser Stelle mal meinen Dank aussprechen dass sich einige doch versuchen, das Problem zu lösen.

Michael

[micha81929]

Helfen werde ich micha1929 nicht mehr, mir ist das zu ignorant.
Grüße, Günther

Naja, viel Hilfe war es bis jetzt auch nicht

[cosmac]

hi,

Bisher ging ich davon aus, dass (nicht nur) Debian seine Systemzeit aus der hardware-Uhr holt und die auch nicht antastet, es sei denn, dass ich ihm explizit sage, es also bewusst so umkonfiguriere, dass es sie woanders herholen und dann die Hardware-Uhr danach stellen soll. Ist dem nicht mehr so?

Früher hat beim Booten der Kernel die RTC gelesen. Anschließend hat hwclock die RTC noch einmal gelesen und die Systemuhr neu gestellt. Das war angeblich für Dateisysteme wie FAT nötig.

Im normalen Betrieb war ntpd nicht installiert und die RTC ist nicht mehr angefasst worden, auch nicht, wenn man die Systemuhr mit date neu gestellt hat. ABER: beim Runterfahren wurde hwclock aufgerufen und das hat die Systemzeit in die CMOS-Uhr geschrieben - egal, ob die Systemzeit ge- oder verstellt wurde. Soweit ich weiß, war das bei allen Debian-Installationen (auch minimalen) so.

Mit ntpd schreibt der Kernel die Systemzeit alle 11 Minuten in die CMOS-Uhr, aber nur, solange der ntpd sauber synchronisiert. Auch wenn der ntpd nicht automatisch installiert wird: die meisten Leute installieren ihn doch von Hand, sobald irgendetwas mit der Uhrzeit nicht stimmt. Evt. ist er auch bei einer kompletten Desktop-Installation dabei.

Heute habe ich etwas sehr merkwürdiges beobachtet: Wenn ich aus Linux die HArdwarezeit abrufe (hwclock -D), steht da mit korrektem Datum eine Uhrzeit von 89:18:23 . Die zusätzlichen 68 Stunden zur tatsächlichen Uhrzeit 21:18:23 entsprechen genau den 2 TAgen und 20 Stunden, die die Linux Systemzeit in die Zukunft verschoben ist.

Time read from Hardware Clock: 2016/06/04 89:18:23

Das könnte dann passieren, wenn die RTC auf AM/PM statt auf 24-Stunden eingestellt ist und das Programm (hwclock? systemd-hwclock???) nicht damit rechnet (Das interne Format der RTC ist entweder 0..23 Stunden oder 0..11 Stunden plus ein AM/PM-Bit an der Bit-Position, die 80 Stunden entspricht). Das wäre (auch) für mich ein Grund, die CMOS-Batterie zu tauschen, idealerweise wäre der Rechner für 10 Minuten komplett ohne Strom. Leider sind dann alle BIOS-Einstellungen weg.

VT: bisher haben alle Programme beide Formate richtig ausgelesen; systemd macht das nicht, weil die RTC gefälligst im 24-Stunden-Format zu laufen hat :VT-Smilie:

[micha81929]

Dass die Bios-Uhr defekt ist, halte ich zumindest für um Längen wahrscheinlicher, als dass ntp sich irgendwoher irgendeine Mondzeit einfängt - jedenfalls habe ich sowas noch nicht gelesen. Nur müsste er dazu mal sagen, was denn die Bios-Uhr (bei Debian UND windows) sagt, statt blind mit irgendwelchen Drift-Zahlen um sich zu werfen.

Das sehe ich aber ganz anders: Wenn die Bios-Zeit ganz präzise läuft, solange der Rechner 'ne Woche oder so runtergefahren ist, oder wenn er mehrere Tage unter Windows 7 läuft, spricht das doch wohl ziemlich klar dagegen, dass die BIOS/Hardware/RTC/CMOS Uhr oder wie immer man die nennt die Ursache des Problems ist.
Wenn dagegen Linux Debian einen Tag läuft (mit oder ohne NTP, ist völlig egal), dann kommt es systematisch zu diesen Zeitverschiebungen. Ich habe glaube ich oft genug genau die ausgelesenen System und Hardware-Zeit hier in den Thread reingeschrieben, als Kopie von date oder hwclock, aber auch als Screenshot aus dem Bios und aus Windows. Musst Du bloss mal ein paar Beiträge zurück blättern (der Thread hat übrigens 3 Seiten, nur zur Orientierung).

Hochachtungsvoll
Micha

[NAB]

Das könnte dann passieren, wenn die RTC auf AM/PM statt auf 24-Stunden eingestellt ist und das Programm (hwclock? systemd-hwclock???) nicht damit rechnet (Das interne Format der RTC ist entweder 0..23 Stunden oder 0..11 Stunden plus ein AM/PM-Bit an der Bit-Position, die 80 Stunden entspricht). Das wäre (auch) für mich ein Grund, die CMOS-Batterie zu tauschen, idealerweise wäre der Rechner für 10 Minuten komplett ohne Strom. Leider sind dann alle BIOS-Einstellungen weg.

Aha? Sowas hatte ich auch überlegt ... aber dann müssten ja plötzliche 80-Stunden-Sprünge auftauchen, gegen 12 Uhr Mittags ... und danach berichtete micha81929 von einer sich konstant oder stückweise verstellenden Uhr.

Und was hat die Batterie damit zu tun? Nach meiner Erfahrung, mit leerer Batterie vergisst das Mainboard ohne Strom so ziemlich alles, und stellt die Uhrzeit auf sonstwann zurück. Das müsste auch unter Windows auftreten. Aber solange es Strom bekommt, läuft die Uhr trotzdem zuverlässig.

micha81929, du müsstest die Sache mal kontinuierlicher beobachten in regelmäßigen Abständen, und nicht immer nur nen Tag später den neusten Zeitverzug verkünden ... dass die Uhr falsch geht, wissen wir inzwischen.

[detix]

Michael, schon mal über einen verrückt gewordenen cronjob nachgedacht?

[cosmac]

Das könnte dann passieren, wenn die RTC auf AM/PM statt auf 24-Stunden eingestellt ist und das Programm (hwclock? systemd-hwclock???) nicht damit rechnet (Das interne Format der RTC ist entweder 0..23 Stunden oder 0..11 Stunden plus ein AM/PM-Bit an der Bit-Position, die 80 Stunden entspricht). Das wäre (auch) für mich ein Grund, die CMOS-Batterie zu tauschen, idealerweise wäre der Rechner für 10 Minuten komplett ohne Strom. Leider sind dann alle BIOS-Einstellungen weg.

Aha? Sowas hatte ich auch überlegt ... aber dann müssten ja plötzliche 80-Stunden-Sprünge auftauchen, gegen 12 Uhr Mittags ... und danach berichtete micha81929 von einer sich konstant oder stückweise verstellenden Uhr

Stimmt allerdings. Aber mit dem einen 80-Stunden-Bit kommen wir auch nicht auf die 68 Stunden, es ist also etwas komplizierter. Und außer der einen Zeile mit "89:18:23" und den 68 Stunden finde ich in diesem Thread keine überzeugenden/widerspruchsfreien Angaben

Und was hat die Batterie damit zu tun? Nach meiner Erfahrung, mit leerer Batterie vergisst das Mainboard ohne Strom so ziemlich alles, und stellt die Uhrzeit auf sonstwann zurück.

Mit ganz leerer Batterie ja, aber kurz vorher setzt erstmal der Takt aus, während der Speicher noch gut funktioniert.

Aber solange es Strom bekommt, läuft die Uhr trotzdem zuverlässig.

Das ist das nächste Problem: was heißt "runtergefahren"? Es gibt diverse Standby-Arten und die RTC wird vielleicht auch im tiefsten Standby noch aus der Steckdose versorgt. Dann kommt die Batterie garnicht ins Spiel

Trotzdem könnte es helfen, den Rechner komplett stromlos zu machen. Nämlich für (gegen?) den Fall, das sich die RTC "von selbst" auf AM/PM oder binary statt BCD umgestellt hat. Das BIOS würde sie dann beim ersten Einschalten wieder richtig initialisieren.

[guennid]

@cosmac
Danke für die detaillierten Erklärungen.
Ich habe hier zwei jessies, eins mit und eines ohne systemd. ntp gibt es auf keinem von beiden. Aber okay, was einem Debian heutzutage bei einer Standardinstallation alles ungefragt unterjubelt, weiß ich auch nicht.

die RTC wird vielleicht auch im tiefsten Standby noch aus der Steckdose versorgt.

Keine Ahnung, ob man den Zustand nach shutdown -h now noch als standby bezeichnet, aber so ist das wohl. Guckst du hier: viewtopic.php?f=13&t=160758&hilit=batterie

Grüße, Günther

[NAB]

Aber mit dem einen 80-Stunden-Bit kommen wir auch nicht auf die 68 Stunden,

*hüstel* ... das sind aber genau 80 Stunden!
Ausgelesene Uhrzeit:
89:18:23
Echte Uhrzeit laut micha81929:
09:18:23 PM bzw. 21:18:23
Darum war ich von deinem Hinweis ja so begeistert, aber ...

finde ich in diesem Thread keine überzeugenden/widerspruchsfreien Angaben

So geht's mir auch. Ich bin mir nicht mal sicher, ob die Hardware-Uhr unter Debian spinnt, ob "Debian liest Hardware Zeit inkorrekt" stimmt, oder ob die Systemuhr falsch geht, und Debian dann die Hardwareuhr verstellt.

Ehm ... was würde denn passieren, wenn die RTC in diesem AM/PM-Format läuft, Debian die Zeit mit 80-Stunden-Bonus ausliest ... und sie dann zu korrigieren versucht, indem ein BCD-Format reingeschrieben wird? Die man-page ist da nicht wirklich erhellend und scheint nur ein Format zu kennen:
http://linux.die.net/man/4/rtc
Und der Treiber scheint im schnellen Überfliegen nur BCD und Binary zu kennen:
http://lxr.free-electrons.com/source/dr ... rtc-cmos.c

Müsste Windows nicht auch darunter leiden, wenn die RTC nicht auf BCD läuft?

micha81929, was sagt denn überhaupt:

Code: Alles auswählen

cat /proc/driver/rtc

Zu dem "synchronization failed" finde ich auch nichts Erleuchtendes ... hier:
https://bugzilla.redhat.com/show_bug.cgi?id=667288
ist ein interessanter, aber eigentlich zu alter Bugreport.
Und hier gibt's eine Regression, die ist aber eigentlich zu neu:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=782726

[micha81929]

micha81929, du müsstest die Sache mal kontinuierlicher beobachten in regelmäßigen Abständen, und nicht immer nur nen Tag später den neusten Zeitverzug verkünden ... dass die Uhr falsch geht, wissen wir inzwischen.

Ich bin vermutlich der Lösung einen Schritt näher gekommen. Ich habe wie weiter oben beschrieben in etc/default/hwclock.config jetzt die Option HWCLOCKACCESS=0 gesetzt (ist defaultmässig immer YES) und in adjtime die Zeitdifferenz auf nahe 0 gestellt.

Die Systemzeit stand wie vor 3 Stunden beschrieben auf fast 3 Tage in der Zukunft

root@Michas-BigAsus:/home/michael# date
Sa 11. Jun 18:23:46 CEST 2016

Als ich jetzt Debian runter gefahren hatte und ins BIOS geschaut habe stand dort die Korrekte Zeit
Mi 08. Jun 22:23:46 (das ist neu und erstmal sehr erfreulich)

Jetzt habe ich Debian wieder durch Dual-Boot gestartet und - oh Wunder - es hat die korrekte Bios-Zeit als Systemzeit übernommen (einweiterer Schritt zur Losung).

ABER: jetzt bin ich gleich mal in den Suspend-Modus gegangen und dann wieder zurück und - oh Schreck - die Linux Systemzeit hat sich wieder auf Sa 11. Jun 18:23:46 CEST 2016 vorgestellt (innerhalb von nur etwa 10 Sekunden). Das heisst durch den kurzen Suspendmodus hat sich die Systemzeit diesmal wieder 68 Stunden in die Zukunft verschoben.

[NAB]

micha81929, das ist interessant ... erstens, weil es glatt mehrere Stunden sind, um die sich die Uhr verstellt hat, und zweitens, weil es in einem sehr großen Sprung passiert ist. Das ist ganz sicher keine falsch gehende Uhr.

Und nach cosmacs Rechnung ...
22 Uhr = 10 PM = 80 + 10 = 90 ... tja, da weiß ich leider nicht, was mit dem PM-Bit passiert bei Uhrzeiten größer "9".

Edit: Folgenden Absatz umgeschrieben:
Die 90 Stunden müssten gerechnet werden ab dem 8.Jun, 0 Uhr. Nach 72 Stunden (3 Tagen) wären wir beim 11. Jun, 0 Uhr. Dann wären noch 18 Stunden übrig, und dir wird der 11. Jun, 18 Uhr angezeigt. Kommt perfekt hin!

Kannst du das noch mal ausprobieren, zu einer Uhrzeit zwischen 0 und 9, sowohl Vormittags als auch Nachmittags?

Wir erwarten, dass Vormittags gar nichts passiert, und sich die Uhr Nachmittags um +80 Stunden verstellt, aber nach amerikanischer Zeitangabe ... aus 13 Uhr = 1 PM wird 1 Uhr morgens plus 80 Stunden.

Genau wie in deinem ersten Beispiel. Aus 21 Uhr wird 9 Uhr plus 80 Stunden. Du landest dann 3 Tage (= 72 Stunden, 8 übrig) später bei 17 Uhr (9+8).

Ich denke, die adjtime kannst du löschen, oder auf 0 setzen ... bei derartigen plötzlichen Sprüngen hilft die eh nicht und versaut höchstens die Testergebnisse.

[micha81929]

Kannst du das noch mal ausprobieren, zu einer Uhrzeit zwischen 0 und 9, sowohl Vormittags als auch Nachmittags?

Wir erwarten, dass Vormittags gar nichts passiert,

Hallo NAB, Ich habe es gerade eben (d.h. um 00:50 Uhr) nochmal gemacht (Suspend und Wiedeanmeldung) und es ist tatsächlich so wie von Dir vorhergesagt: es hat sich jetzt garnichts verändert an der Systemzeit.
Nach Deiner Argumentation müsste der Fehler dann heute ab Mittag wieder auftreten. Ich werde das verfolgen und den Thread auf dem Laufenden halten.
Ich hätte gedacht, dass das Zeitformat (24h oder 12h AM/PM) nur etwas mit der Darstellung zu tun hat, aber nicht mit der Berechnung von Zeit im System. Wenn das tatsächlich die Ursache des Problems sein sollte, ist das doch wiklich ein Bug, oder ? Zumal ich definitiv bei der Debian Installation nirgendwo spezifiziert hatte, dass Zeiten als 12h AM/PM berechnet werden. Das ist ja bisschen so, als würde man ein Auto bauen, bei dem die Gewinde alle metrisch sind und man dann versucht, Bolzen mit Zoll-Massen reinzuschrauben. Also das kann doch von den Debian Entwicklern nicht so beabsichtigt worden sein.

[NAB]

Lies dir die Aussagen von cosmac noch mal durch ... ich hab von diesem AM/PM-Format in der Hardwareuhr zwar auch noch nie gehört, aber ich glaub kaum, dass er sich das ausgedacht hat.

Mach mal noch ein paar Tests, ob das hinkommt mit diesem "plus 80 Stunden", und falls ja, würd ich alles ausprobieren, was cosmac vorgeschlagen hat. Eventuell kannst du die Zeitangabe auch im BIOS umstellen?

(Und wenn's einmal geht, kann das auch Zufall sein, Probier das ruhig zwei, drei mal aus)

[NAB]

Man, micha81929, ich hab mich verrechnet ... lies dir mein Posting über deinem noch mal durch, ich hab's korrigiert ... das kommt rechnerisch perfekt hin, auch mit Zeiten größer 9.

Und ich bin mir nicht sicher, was zwischen 12 und 13 Uhr passiert ... kommt drauf an, ob er mit 0 PM oder 12 PM rechnet. Ab 13 Uhr bist du sicher bei 1 PM.

Edit: und noch ein Test fällt mir ein: Sorg mal dafür, dass Windows nicht ins Internet kommt und auch nicht an die Fritzbox und starte es dann nach Mittag .... wie spät hat Windows es dann?

[micha81929]

(Und wenn's einmal geht, kann das auch Zufall sein, Probier das ruhig zwei, drei mal aus)

Es war leider wirklich nur Zufall,dass es vorhin geklappt hat.

Habe soeben (nach ca. 7,5 Stunden im Suspend Modus) Debian wieder aufgerufen, und die Systemzeit steht auf

root@Michas-BigAsus:/home/michael# date
So 12. Jun 16:13:10 CEST 2016
root@Michas-BigAsus:/home/michael#

(also genau 64 Stunden in der Zukunft).

Ich gehe nochmal alle bisherigen Vorschläge durch und sehe ob ich es irgendwie in den Griff bekomme.