ntp.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
Active: active (running) bla-bla-bla …
So unless you have a specific desire to run ntpd …
sudo apt purge ntp
then reboot the computer and see whether systemd-timesyncd is active and remains active.
You should then see that the time advances normally while the computer is booted, the time freezes at shutdown, the time unfreezes at startup, and then corrects as soon as the computer can get a network connection.
However I would pursue Purism for confirmation that this computer simply doesn’t have a battery and a clock chip to maintain the time while powered off.
I have one computer that has a battery and clock chip but the computer ships with the battery switched off! (That’s because the battery is a rechargeable, hard-wired one.) Did you read the “Quick Start Guide”? 
okay but the time DOES sync when i go online. that’s NOT the issue (if ntp is or not installed).
the real issue is that what can be observed in the screen-grab from above … when i manually try to set it to auto-update in the GNOME-settings-GUI it shows as DISABLED which it should NOT do because it leaves the user with the impression that the time does NOT sync when in reality it does …
a GUI should ALWAYS reflect what the back-end software (or services in this case, are doing - yes they are NOT conflicting but that isn’t the point)
I dunno if @anon10067017 is still with us, but that is definitely a typo. I dunno if it was wrong in his /etc/ntp.conf, or if he accidentally fat-fingered the post. NPT appears to be some sort of quasi-charity. NTP (https://ntp.org) is a home of the venerable Network Time Protocol, which I have used to synchronize my time since I ran OS/2 Warp in the early 1990’s.
by the way the command i used to get rid of ntp is this :
sudo apt autoremove --purge ntp
it took some other no longer dependent packages with it though so beware of that in case you need them …
i confirm that after reboot the GUI works as expected and shows a visual representation as expected. problem solved
systemd-timesyncd is still there ofc
1 Like
It would still be good to have confirmation from Purism that this computer (Librem Mini) simply doesn’t have a battery and a clock chip to maintain the time while powered off.
my impression is that it does NOT have any of those hw you listed because if i disconnect the power-brick from the UPS during my sleep hours then when i wake up and power-up again the clock is ALWAYS reset to the default July 15th 2020 date (something with that date in the BIOS i imagine)
That shouldn’t happen now that you have fixed your time client. Instead it should reset to the time of last shutdown.
regardless of what should or should not happen, this is what i could observe happening with my Librem-Mini …
What does
ls -l /var/lib/systemd/timesync/clock
initially (at boot, before network is available) and progressively (over time) show for the time on the file while the computer is booted?
1 Like
hmm. i see … yes it seems to be indicating some time (1 day before the current present time)
meaning now it’s 14 oct and it shows it is as 13 oct
when i try to cat out the file it doesn’t show anything …
it still doesn’t explain the 15 july date … might be some config somewhere …
That’s right. It’s empty. The purpose of the file is only to show the time of the last sync. (I am unclear on whether it’s the time that was derived from the last sync or the time at which that last sync occurred - but there should be negligible difference between those times.)
On my system, the time syncs every 2048 seconds (that’s the default), so the time on that file jumps forward about 34 minutes at a time, about every 34 minutes. That’s probably over the top for my purposes - don’t need it highly accurate and system clock is not so inaccurate.
Which presumably means that you shut the computer down the day before.
According to the man page … if time synch was not possible then the file shows the date of the systemd build i.e. it would be the same on each boot if time synch was never possible (e.g. airgapped network with no local NTP server or airgapped computer) but the date would settle on a new fixed starting date after upgrading systemd (but again such an upgrade might never happen in a truly airgapped environment).
that would be a highly accurate assumption indeed that is when i manually enabled the sync to happen from the GUI then disabled it again (i don’t need mine to sync daily just when i want to check if noticeable differences happen)
btw my electronic hand-watch is a few minutes ahead of my ntp-synced system-clock 
that’s probably why i’m a few minutes early everytime 
1 Like
@kieran just a short update for the latest
sudo dmidecode
;; BIOS Information
;; Vendor: coreboot
;; Version: 4.12-Purism-4
;; Release Date: 11/06/2020
on my Librem-Mini-v1/PureOS-9-Amber(Stable)/GNOME when completely disconnected from the power-source and then after a few hours of complete power-starvation when powered-ON again i find the time-clock reset to > nov 06, 2020 @ 03:00 morning-time (i believe this would be AM for American convention)
that ofc is not a major issue for me since i can update-manually the time-server when online from the www but for people that do NOT have internet available on demand it might be somewhat problematic if you don’t have another accurate-time device to manually set the values into the GNOME settings GUI
1 Like
I don’t know. It’s still not working the way I would expect. It is still working the way the documentation suggests that it can under certain assumptions that various things aren’t working properly (since there are multiple fallbacks to maintain the correct time before reverting to a build date).
It was confirmed here that the Librem Mini v2 has an RTC with button cell.
Do you want to open yours up and see whether you can see a button cell? I would carefully extract the battery and check the orientation (polarity) of the battery. If you have a multimeter, I would also check the voltage on the battery.
1 Like
i don’t want to … but when i get my v2 and i open it up i’ll do the same thing to the v1
is it the upper side or the bottom side (with the SOC) that i need to inspect ?
No idea where the button cell is. If noone else jumps in with the answer, I suggest you ask Purism. After all, eventually the battery goes flat and every customer will have to replace the button cell.
i have a hard time believing that Purism would ship my v1 with a dead battery … it’s only been a few months since july and a CR2032 (what it usually is on most desktop-motherboards) lasts longer than 6 months (let’s say it was last checked in june)
1 Like
underside, the entire board must be removed from the chassis to access. I thought I’d taken a pic I could post, but apparently not.
urgh ! i’d rather not mess with it in such a cramped chassis. i don’t mind getting ‘dirty’ in a standard mITX or larger desktop case but the NUC is so tight … oh well, i guess i’ll see when i get the v2