Wenn der Kernel fsck ausführt, sollte doch Mount count wieder auf 0 gesetzt werden, weshalb systemd es nicht mehr fsck-en würde.
Ja, ntpd läuft

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?
Keinen, aber 'less /etc/adjtime' zeigt mir nach dem nächsten Boot: 
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?
natürlich... ist ja oft genug gesagt worden.
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:
  • 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
Klingt nach der Fenster-zu-und-auf-Methode, aber in diesem Moment fällt mir nix besseres ein.
Systemzeit: UTC
BIOS nach Boot: UTC-2

Meine Einstellungen werden also nicht übernommen.
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.
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?
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!
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....
Ausser das was in der Anleitung für Einsteiger steht, wüßte ich nicht was an der Zeit noch zu drehen wäre.
Mal eine dumme frage, hast du Port 123 freigegeben? Über diesen wird nämlich die Sync. Durchgeführt.
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.
Ach, hattest du dieses schon probiert ?
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. 🙂
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. "
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. "
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.
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!
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!
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.
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.