You are not logged in.
I've been using Chrony to manage my system time ever since installing Arch, so this has hardly been a bother, but I have noticed in journalctl logs that upon boot the system time is determined to be something silly at first and only a bit later does it get reset to the correct time.
$ chronyc rtcdata
RTC ref time (UTC) : Fri May 19 07:33:10 2023
Number of samples : 14
Number of runs : 9
Sample span period : 21m
RTC is fast by : -31802080.000000 seconds
RTC gains time at : -6.659 ppmI can of course run `sudo chronyc trimrtc` at which point the reference time is set to the current time but that doesn't seem to last across reboots (and sometimes not even across my laptop sleeping).
Is this the wrong way to correct the RTC clock? Is my configuration wrong somehow? Let me know if there's any other info I should provide, I don't really understand how this part of my system works.
Last edited by emilylime (2024-05-23 15:23:23)
Offline
Is the RTC bogus pre-boot (ie. in the UEFI/BIOS)?
What kind of battery supports the RTC? Do you completely cut power from the system after a shutdown?
Online
This is the first mention in journalctl: "systemd[1]: System time before build time, advancing clock." — plenty into the boot.
I'm using an unmodified Asus TUF Dash F15, so I would expect it to be built such that the RTC still gets power even when shut down.
Offline
The idea was to shut down, get a coffee, boot cold into the UEFI and check the clock there.
I would expect it to be built such
Judging from other circumstances where the series showed up ("gaming" notbook that doesn't allow you to control voltage, clocks or timings… no idea whether that applies to your model) I'd curb my expectations and check what it actually does.
Online
Sorry, I guess I'll mark this as solved for now as I can no longer reproduce.
Offline