Good to hear from you...
OK, I get the design choices made for the Zymkey.
In my case, main usage for the PI is to boot offline (no network connection available), it emits its own WIFI (access point mode) without password. PI is configured to share its internet connection whenever connected to a router using ethernet.
The PI is usually plugged out after usage (a few hours)... so no proper shutdown scripts are currently called is that a problem regarding the zymkey way of doing things?
I understand that as NTP can not be run successfully while booting offline, Zymkey should set the system time, even if last shutdown wasn't properly done.
Currently, once booted (either ethernet connected or not) , I log in via ssh, and I get
Last login: Fri Jan 2 02:12:09 1970.
Once logged in:
pi@xxx:~ $ date
vendredi 2 janvier 1970, 02:26:39 (UTC+0100)
(friday Jan, 2nd, 1970 ...)
Now how can I ensure that the systemd boot scripts are correctly run?
When you say:
You should be able to see this in the console.
Where do you refer I should check?
How can I check the time currently stored in the Zymkey?
I've done nothing more than the installation scripts on an existing system, so would a previous DS3231 RTC configuration be in conflict with Zymkey?
Is it possible that my previous config has somehow made the date overwritten in the Zymkey?
Sorry to have so many questions for such trivial things, I'm more into devs than in Linux
4 last lines of
#cat /var/log/syslog | grep Zymkey:
Jan 1 01:00:07 ____ systemd: Starting Restore System Clock from Zymkey...
Jan 2 09:17:58 ____ systemd: Started Restore System Clock from Zymkey.
Jan 2 09:17:58 ____ systemd: Starting Zymkey Interface Connector...
Jan 2 09:17:58 ____ systemd: Started Zymkey Interface Connector.
In python, trying to get time form zymkey
print('get_time(): ' + str(zymkey.client.get_time()))
It appears factory set time on the zymkey has been overwritten by some operations of mine...
For the DS3231 I had to update /boot/config.txt, and forgot to remove before starting the software installation procedure
Might this have something to do with a possible rewriting the key?