Wenn der Kernel fsck ausführt, sollte doch Mount count wieder auf 0 gesetzt werden, weshalb systemd es nicht mehr fsck-en würde.
Zeitproblem
- Bearbeitet
Ja, ntpd läuft
Hier mal die komplette Ausgabe von timedatectl, nachdem ich 'timedatectl set-local-rtc 0' ausgeführt habe:
Hier mal die komplette Ausgabe von timedatectl, nachdem ich 'timedatectl set-local-rtc 0' ausgeführt habe:
Local time: Do 2013-08-08 10:10:01 CEST
Universal time: Do 2013-08-08 08:10:01 UTC
RTC time: Do 2013-08-08 08:10:01
Timezone: Europe/Berlin (CEST, +0200)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
So 2013-03-31 01:59:59 CET
So 2013-03-31 03:00:00 CEST
Next DST change: DST ends (the clock jumps one hour backwards) at
So 2013-10-27 02:59:59 CEST
So 2013-10-27 02:00:00 CET
Dann ein reboot und nochmal 'timedatectl':
Local time: Do 2013-08-08 08:14:12 CEST
Universal time: Do 2013-08-08 06:14:12 UTC
RTC time: Do 2013-08-08 06:14:12
Timezone: Europe/Berlin (CEST, +0200)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: yes
DST active: yes
Last DST change: DST began at
So 2013-03-31 01:59:59 CET
So 2013-03-31 03:00:00 CEST
Next DST change: DST ends (the clock jumps one hour backwards) at
So 2013-10-27 02:59:59 CEST
So 2013-10-27 02:00:00 CET
Warning: The RTC is configured to maintain time in the local time zone. This
mode is not fully supported and will create various problems with time
zone changes and daylight saving adjustments. If at all possible use
RTC in UTC, by calling 'timedatectl set-local-rtc 0'.
> If at all possible use RTC in UTC, by calling 'timedatectl set-local-rtc 0'.
Welchen Fehler gibts denn, wenn du das versuchst?
Welchen Fehler gibts denn, wenn du das versuchst?
- Bearbeitet
Keinen, aber 'less /etc/adjtime' zeigt mir nach dem nächsten Boot:
Wer ändert das vor/nach dem Booten. Ein heimlich eingebauter Troll!?
Aber wie schon gesagt, habe ich das Verhalten nicht zum ersten Mal. Liegt das daran, dass der Kernel die von mir gemachten Änderungen nicht mag? Warum?
0.000000 1375948643 0.000000
1375948643
LOCAL
/etc/adjtime (END)
obwohl da doch eigentlich 'UTC' wie direkt nach dem Befehl stehen sollte oder?Wer ändert das vor/nach dem Booten. Ein heimlich eingebauter Troll!?
Aber wie schon gesagt, habe ich das Verhalten nicht zum ersten Mal. Liegt das daran, dass der Kernel die von mir gemachten Änderungen nicht mag? Warum?
Hast du, wie das Känguru meinte, auch "rm /etc/adjtime" vor timedatactl ausgeführt?
- Bearbeitet
natürlich... ist ja oft genug gesagt worden.
- Bearbeitet
Bei mir wird keine /etc/adjtime angelegt. Keine Ahnung warum.
Die Ausgabe von timedatectl nach timedatectl set-local-rtc 0 sieht gut aus. Doof das nach dem Reboot dort wieder Murks steht. Wie kommt dein System darauf das du in UTC und localtime gleichzeitig sein kannst, obwohl UTC und localtime definitiv 2h auseinander sind? Versuch mal folgendes:
Die Ausgabe von timedatectl nach timedatectl set-local-rtc 0 sieht gut aus. Doof das nach dem Reboot dort wieder Murks steht. Wie kommt dein System darauf das du in UTC und localtime gleichzeitig sein kannst, obwohl UTC und localtime definitiv 2h auseinander sind? Versuch mal folgendes:
- BIOS-Uhrzeit(RTC) korrekt auf UTC stellen (paar Sekunden sind egal, die Stunden:Minuten sollten stimmen)
- booten
rm /etc/adjtime
systemctl stop ntpd
- Systemzeit prüfen/stellen
timedatectl set-local-rtc 0
- neustarten
- Bios Uhr prüfen
Systemzeit: UTC
BIOS nach Boot: UTC-2
Meine Einstellungen werden also nicht übernommen.
BIOS nach Boot: UTC-2
Meine Einstellungen werden also nicht übernommen.
- Bearbeitet
Mach doch mal ein
hwclock -w --utc
Edit: Moment, dass das BIOS 2 Stunden zurück ist, ist doch ganz normal und verwechselst du nicht UTC und Lokalzeit?UTC-2 nicht UTC!
Das BIOS ist dann 4 Stunden zurück.
Wenn die Zeit in adjtime festgelegt wird, dreht sich alles nur darum:
warum wird dieser Eintrag, der ja richtig von timedatectl richtig erstellt wird, immer wieder vor/nach dem Booten nach LOCAL geändert? Welche Konfiguration sorgt dafür? (Kernelparameter?)
Alles andere passt doch. Das würde auch erklären, warum ich ähnliches in der Vergangenheit erlebt habe.
Das BIOS ist dann 4 Stunden zurück.
Wenn die Zeit in adjtime festgelegt wird, dreht sich alles nur darum:
warum wird dieser Eintrag, der ja richtig von timedatectl richtig erstellt wird, immer wieder vor/nach dem Booten nach LOCAL geändert? Welche Konfiguration sorgt dafür? (Kernelparameter?)
Alles andere passt doch. Das würde auch erklären, warum ich ähnliches in der Vergangenheit erlebt habe.
- Bearbeitet
Ich habe noch einen alten Beitrag rausgekramt in Sachen RTC setzen:
https://forum.archlinux.de/viewtopic.php?id=22565
Könnte euch noch was bringen.
Ich habe schon lange nicht mehr ausprobiert ob die Hardwareuhr beim Runterfahren gesetzt wird.
Nachtrag:
Ich habe mal die Systemzeit falsch eingestellt. Beim Runterfahren wird von der Systemzeit zur RTC NICHT umgestellt.
Oder auch anders gesagt, ist die RTC falsch eingestellt, so wird beim neu booten die Sytemzeit immer zuerst falsch sein bis man mit ntp die Zeit korregiert hat.
Mit dem service hwclockende aus dem alten Beitrag wird die RTC korregiert.
Könnte man mit ins ntp Wiki bringen. Oder separat als „ZEIT“ .
In der Anleitung für Einsteiger steht auch drin das die RTC NICHT überschrieben wird. Ist auch korrekt so wenn mehrere Betriebssysteme auf dem Rechner sind. Nur eines davon sollte die RTC überschreiben. Man muß Arch-linux per Service das extra einrichten.
Wollt ihr ein Wiki dazu?
https://forum.archlinux.de/viewtopic.php?id=22565
Könnte euch noch was bringen.
Ich habe schon lange nicht mehr ausprobiert ob die Hardwareuhr beim Runterfahren gesetzt wird.
Nachtrag:
Ich habe mal die Systemzeit falsch eingestellt. Beim Runterfahren wird von der Systemzeit zur RTC NICHT umgestellt.
Oder auch anders gesagt, ist die RTC falsch eingestellt, so wird beim neu booten die Sytemzeit immer zuerst falsch sein bis man mit ntp die Zeit korregiert hat.
Mit dem service hwclockende aus dem alten Beitrag wird die RTC korregiert.
Könnte man mit ins ntp Wiki bringen. Oder separat als „ZEIT“ .
In der Anleitung für Einsteiger steht auch drin das die RTC NICHT überschrieben wird. Ist auch korrekt so wenn mehrere Betriebssysteme auf dem Rechner sind. Nur eines davon sollte die RTC überschreiben. Man muß Arch-linux per Service das extra einrichten.
Wollt ihr ein Wiki dazu?
Danke für den Tip, bei mir läuft ntpd durch.
Und die RTC wird ja nicht verstellt. Einmal gestellt, bleibt sie dort, wo sie hingehört.
Leider wird die dort eingestellte Zeit (UTC) nach jedem Boot als Local interpretiert. Das ist falsch. Und nicht zu ändern.
Darin besteht das Problem. Mein Rechner ist nicht dauerhaft auf UTC umzustellen, da er sich immer wieder selber auf Local umstellt.
Die RTC läuft auf UTC, wird aber als LOCAL interpretiert!
Und die RTC wird ja nicht verstellt. Einmal gestellt, bleibt sie dort, wo sie hingehört.
Leider wird die dort eingestellte Zeit (UTC) nach jedem Boot als Local interpretiert. Das ist falsch. Und nicht zu ändern.
Darin besteht das Problem. Mein Rechner ist nicht dauerhaft auf UTC umzustellen, da er sich immer wieder selber auf Local umstellt.
Die RTC läuft auf UTC, wird aber als LOCAL interpretiert!
Ausser das was in der Anleitung für Einsteiger steht, wüßte ich nicht was an der Zeit noch zu drehen wäre.sanni schriebDanke für den Tip, bei mir läuft ntpd durch.
Und die RTC wird ja nicht verstellt. Einmal gestellt, bleibt sie dort, wo sie hingehört.
Leider wird die dort eingestellte Zeit (UTC) nach jedem Boot als Local interpretiert. Das ist falsch. Und nicht zu ändern....
Mal eine dumme frage, hast du Port 123 freigegeben? Über diesen wird nämlich die Sync. Durchgeführt.
Ach, hattest du dieses schon probiert ?Goshawker schriebIch bin zwar nur ein leie in Sachen Linux, aber "hwclock -w" ist meiner Meinung nach die localetime.
Versuch mal "hwclock -wu" das dürfte die utc sein.
Wie kriege ich raus, ob der Port freigegeben ist?
Ja, den hwclock -wu habe ich auch probiert. Funktioniert einwandfrei -- bis zum Booten!
Sämtliche Befehle funktionieren so, wie sie sollen. Nur mit der Dauerhaftigkeit hapert's noch. 🙂
Ja, den hwclock -wu habe ich auch probiert. Funktioniert einwandfrei -- bis zum Booten!
Sämtliche Befehle funktionieren so, wie sie sollen. Nur mit der Dauerhaftigkeit hapert's noch. 🙂
Wenn dann wir der Port über dein Modem gesperrt. Also musst du auf dein Modem zugreifen und dort den Port freigeben.
Zitat aus dem Wiki: "NTP läuft über den UDP-Port 123. Dieser muss in einer eventuell vorhandenen Firewall freigegeben werden, bzw. muss auf dem Router entsprechendes Portforwarding eingerichtet werden. "
Zitat aus dem Wiki: "NTP läuft über den UDP-Port 123. Dieser muss in einer eventuell vorhandenen Firewall freigegeben werden, bzw. muss auf dem Router entsprechendes Portforwarding eingerichtet werden. "
Otto Normal hat in seinem Haushalt einen Router stehen welcher ausegehende Ports automatisch öffnet. Sonst wär auch nix mit HTTP/S, FTP, SSH, etc. Also mach mal bitte nicht die Pferde scheu bevor wir nicht wissen ob denn ntpd überhaupt ein Problem hat Server zu erreichen. Vor allem da timedatectl auch ausgibt das ntpd erfolgreich synchronisiert.Goshawker schriebWenn dann wir der Port über dein Modem gesperrt. Also musst du auf dein Modem zugreifen und dort den Port freigeben.
Zitat aus dem Wiki: "NTP läuft über den UDP-Port 123. Dieser muss in einer eventuell vorhandenen Firewall freigegeben werden, bzw. muss auf dem Router entsprechendes Portforwarding eingerichtet werden. "
sanni schrieb[…][…] NTP enabled: yes NTP synchronized: yes […]
kann es denn schaden, den Port einfach mal zu öffnen um zu sehen was passiert?
Wie schon gesagt, ich bin ein noob was dieses betrifft aber zumindest bei meinem "Otto Normal Router (Fritz Box 71irgendwas)" habe ich diesen Port geöffnet und siehe da, ich hatte die richtige Uhrzeit.
Außerdem kann man den Port ja auch wieder schließen!
Wie schon gesagt, ich bin ein noob was dieses betrifft aber zumindest bei meinem "Otto Normal Router (Fritz Box 71irgendwas)" habe ich diesen Port geöffnet und siehe da, ich hatte die richtige Uhrzeit.
Außerdem kann man den Port ja auch wieder schließen!
Ich habe hier eine Otto Normal Fritzkiste 7330 SL. Hinter dieser Fritzbox befinden sich drei Rechner. Alle nutzen ntp, alle haben die korrekte Uhrzeit, es ist kein Port geöffnet worden. Warum? Weil das nicht nötig ist. Und auch mit den Routern die ich bereits verschlissen habe, habe ich nie Ports für ntp geöffnet.Goshawker schriebkann es denn schaden, den Port einfach mal zu öffnen um zu sehen was passiert?
Wie schon gesagt, ich bin ein noob was dieses betrifft aber zumindest bei meinem "Otto Normal Router (Fritz Box 71irgendwas)" habe ich diesen Port geöffnet und siehe da, ich hatte die richtige Uhrzeit.
Außerdem kann man den Port ja auch wieder schließen!
Außerdem ist sannis ntpd synchron mit irgendeinem ntp-Server…, aber naja mir fällt im Moment nichts ein was man noch prüfen sollte um hier weiter zu kommen.