On 08/19/2014 08:49 AM, Peter Robinson wrote:
On Tue, Aug 19, 2014 at 1:25 PM, Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> wrote:
A lot of the arm boards, or so I have been told, are like mine; no rtc.
Pretty much all boards, well at least the 20 odd I have, have a RTC,
the problem is that they aren't battery backed.
OK. You got me on that. No battery backup so the RTC comes up at zero
at boot, then progresses properly from there until it gets set.
This is causing a lot of interesting problems with boot up until ntp can set
the time (or is it ntpdate?).
chrony is the default. What are the "interesting" problems?
Your system clock is 44? years early until ntp gets to an ntpd server.
That requires the network to come up which requires perhaps network
login. And a number of processes run with this early clock time. Most
just pass it off, but some might be off.
So I was thing of how to 'fix' this. Over on the Redsleeve list a fellow
that is dealing with this on his RasberryPi noted:
http://zenit.senecac.on.ca/wiki/index.php/Nortc
This might be one solution if someone took it on (I have no skills in coding
or building packages).
But I was thinking of a scripted approach.
First you need a file that has date/time in a format that it can be piped
into the date command like:
date < /etc/fixtime
The image build process would put the build date into this file for
starters. At firstboot, if the time is near zero (some seconds having
passed since poweron), a few things happen:
The fixtime script is run to set the time to the image build date/time.
The fixtime script is set to run at every boot as one of the first
processes.
A cron job is enabled (hourly or dayly) to update /etc/fixtime so the next
boot will have a more current time.
I probably have the skills to write a fixtime script and a cron fixtime
update, but I don't know how to alter the boot process. But I think that
such a process is needed to address all the little oddities that come up
when the system boots with time ZERO. And think about desktop setup where
only after the user logs into wireless can ntp get the time.
A lot of networks, even with restricted wifi networks, provide ntp to
ensure sync of time before login.
Not so, only those that use the Hotspot 1.0 web capture login. If you
are using WPA, no IP until authenticated. No DHCP until authenticated.
And with Hotspot 2.0 getting ready for rollout this fall (I work on
802.11 standards and participate in WiFi Alliance) there will be the
move to working 802.1X EAP/TLS authentication and no IP until done. Now
in many cases, this will be automagic and you 'soon' get network
connectivity and thus time. You COULD get time from the BEACON even
before that, but that would be a change to NetworkManager, and BEACONs
can lie.
I know that there are many things that NEED to get done. This is
perhaps a minor issue. But an issue none the less. I could open up a
bug item on it.
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
