[fedora-arm] Dealing with lack of a real time clock

[Robert Moskowitz]

On 08/19/2014 08:49 AM, Peter Robinson wrote:
> On Tue, Aug 19, 2014 at 1:25 PM, Robert Moskowitz <rgm at htt-consult.com> 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.