User avatar
joedix
Posts: 2
Joined: Thu Jan 23, 2014 4:44 am
Location: Olathe, KS, USA
Contact: Website

fake-hwclock time adjustment

Thu Jan 23, 2014 5:10 am

I am definitely a noob, and this was a "learning" experience.

I had noticed that after a reboot (weezy) the time was in the universal / UTC / GMT, however my local time zone had been set and was correct.
This is the method I used to set my local time zone.
... after login as pi via ssh...
sudo raspi-config
Setup Option: Internationalisation Options
Change Timezone
Geographic Area: US
Time Zone: Central
Setup Options: Finish
but after a reboot "$ date" would be correct...
but "$ cat /etc/fake-hwclock.data" would be off by -5 hours, this makes sense, since I am GMT-5
My fix to correct this small headache (referring to time lapse images saved with GMT-5 filenames).
"$ sudo nano /sbin/fake-hwclock"
See line 29 "date -u '+%Y-%m-%d %H:%M:%S' > $FILE"
I remove "-u" interpreted as Universal or UTC
My new line 29 "date '+%Y-%m-%d %H:%M:%S' > $FILE"
Then I eXited nano "Ctrl X" and "y" to save, and enter for same filename.

Tested by running "$ sudo fake-hwclock"
and then "$ cat /etc/fake-hwclock.data"
and the time matched my local time, hooray!

This also means what when ever you want to manually update your fake-hwclock.data, all you need
to do is run "$ sudo fake-hwclock"

I hope this helps someone.
Joseph Dix
-not a lot to say-

User avatar
Richard-TX
Posts: 1549
Joined: Tue May 28, 2013 3:24 pm
Location: North Texas

Re: fake-hwclock time adjustment

Thu Jan 23, 2014 11:57 am

I am having a problem following what the issue is.

I have never referred to the info in /etc/fake-hwclock.data If I wanted the current time, I would use the date command. Not every system has /etc/fake-hwclock.data so I would avoid using that for portability reasons..

Put another way, I don't really care what the system timezone is. I can always set my own timezone.

# date '+%Y-%m-%d %X'
2014-01-23 05:50:09
# TZ='America/Los_Angeles' date '+%Y.%m.%d %X'
2014.01.23 03:52:47
# TZ='CDT6CST' date '+%Y.%m.%d %X'
2014.01.23 05:53:36
# TZ='CDT7CST' date '+%Y.%m.%d %X'
2014.01.23 04:54:48
# TZ='UTC' date '+%Y.%m.%d %X'
2014.01.23 11:55:55


[/code]

When playing with shell variables in scripts, exporting the variable many be needed.

Code: Select all

TZ=foo
export TZ
Your effort to resolve your issue is most commendable. Well done.

richard
Richard
Doing Unix since 1985.
The 9-25-2013 image of Wheezy can be found at:
http://downloads.raspberrypi.org/raspbian/images/raspbian-2013-09-27/2013-09-25-wheezy-raspbian.zip

User avatar
scruss
Posts: 3068
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: fake-hwclock time adjustment

Thu Jan 23, 2014 2:11 pm

Joe, is your Raspberry Pi connected to a network? If so, ntpd should be running, and it will set the time correctly as soon as it can. Linux expects the system clock to be in UTC, and the whole (massively complex) TZ system makes sure that almost every time that you see is local.

So for me, in Eastern Standard Time, the time is looking like:

Code: Select all

$ date ; date -u 
Thu Jan 23 09:10:29 EST 2014   # ← local time
Thu Jan 23 14:10:29 UTC 2014   # ← UTC system time
The fake-hwclock mechanism is really designed to ensure that computers without an RTC will always have a monotonically increasing (if inaccurate) time clock. This at least would allow you compare file dates by age, which can still be slightly useful. For the very brief time before ntpd kicks in, that's the only time you need to worry about fake-hwclock. I wouldn't actually have spent any time on this; as long as there's a network present, ntpd and TZ manage the complexities of system time so you don't have to.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.
Pronouns: he/him

kurtdcobain
Posts: 24
Joined: Thu Jan 03, 2013 2:42 pm

Re: fake-hwclock time adjustment

Tue Jun 17, 2014 8:13 pm

Thank You very much!!!

gregsmith_to
Posts: 15
Joined: Mon May 14, 2012 1:56 am

Re: fake-hwclock time adjustment

Sun Nov 15, 2015 8:46 pm

I've installed an adafruit DS1307 rtc and it seems to be OK and running on 2015-05-05-raspian-wheezy
This installation, btw, is entirely different from older information that you will generally find on the internet - including the info at adafruit - since it's now a matter of enabling I2C and drivers in raspi-config, and then adding a line to /boot/config.txt:
dtoverlay=i2c-rtc,ds1307

This is discussed here
viewtopic.php?t=97314

So now hwclock appears to work fine ( and 'i2cdetect' doesn't work at all; there is no /dev/i2c* at all)

Except that the rpi still powers up with the same time I turned it off, and the RTC does not appear to have advanced while the power was off. initially I suspected that the DS1307 oscillator was not running on battery (though a scope shows a 32khz wave), but now it appears that 'fake-hwclock' is superseding what's in the hwclock. I.e, during startup, fake-hwclock loads the time from /etc/fake-hwclock.data, and then sometime after that, hwclock -w is done (since the hwclock appears to be matching this wrong time by the time I log in). I've done an experiment where I manually put the /etc/fake-hwclock.data a half hour into the future - using a linux laptop while the rpi was off - and confirmed this.

In other words, I can power it off - change the /etc/fake-hwclock.data to some time in the future, then power it on before that time happens, and that time I selected will be the 'system time', and will also have been set into the RTC, as reported by hwclock -r. This will also occur if the recorded time is in the past (relative to when I do the power up) -- as is the case if I don't tinker with /etc/fake-hwclock.data at all.
I tried putting 'hwclock -s' in /etc/rc.local, but that runs way too late.

While I was gathering information for this, I came across this post which appears to have the proper method. I will try that and in any case will leave this post here as a pointer.

viewtopic.php?t=85683

Update: Agggg. It appears that most of the information in that post is out of date (relating to installing the drivers), but the advice on removing fake-hwclock is there (including removing from crontab). I'll just quote part of that from here

http://blog.remibergsma.com/2013/05/08/ ... pberry-pi/
I talked about the ‘fake-hwclock’ package. Now that we have a hardware clock, we should remove this package and it’s crons.

Code: Select all

apt-get remove fake-hwclock
rm /etc/cron.hourly/fake-hwclock
update-rc.d -f fake-hwclock remove
rm /etc/init.d/fake-hwclock
Enable the ‘hwclock.sh’ script (part of util-linux), instead:

Code: Select all

update-rc.d hwclock.sh enable

The above (complete removal of fake-hwclock) appears to override the advice in the elevendroids link, which contains a less aggressive removal

http://www.elevendroids.com/2012/12/set ... -raspbian/

which is
We can now disable fake-hwclock from running:

Code: Select all

# update-rc.d fake-hwclock remove
Either way, this means my SD card probably won't work very well at all on a PI not equipped with an RTC, but I guess I can deal with that.

UPDATE AGAIN:

No No No...
I removed fake-hwclock and enabled hwclock.sh, using update-rc.d, and reverted /etc/rc.local.
Now the time goes back to Jan 1 1970 when I restart, and 'hwclock -r' says the RTC is corrupted even though the RTC was readable before I restarted. I can restore the time, do a hwclock -w, and then hwclock -r works, and then it fails again on restart and says the RTC is corrupted. So now I'm thinking that I'm pretty thick, and that all this time 'hwclock' was actually talking to fake-hwclock - at least on the read side. (Evidence of writes to the rtc, since it didn't oscillate on battery under after hwclock -w was done).

Is it possible that the 'hwclock.sh' is trying to talk to the RTC before the RTC driver has been set up? Would explain failure to read the time, but not why the RTC is corrupted.

I did not follow the advice in the elevendroids article to modify hwclock.sh - since all of that ( things like 'echo ds1307 0x68 >> $bus/new_device' , and modprobes) appears to be related to the old driver setup which has been superseded by dtoverlay.

I have run out of time to spend on this for today, would appreciate any help.

elbarbudo
Posts: 4
Joined: Sun Dec 11, 2016 3:02 pm

Re: fake-hwclock time adjustment

Tue Mar 27, 2018 7:11 am

I have a strange behavior of my Raspberry PI 2 with OSMC
  • Initial boot has been setup to boot on an hard disk, but there is still a little boot code on the SD
  • the fake-hwclock gives me correct date and time
  • NTP is running
But on the journalctl I always have a start time of Thu 2016-11-03 18:16:43 CET that is neither "the Epoch" nor the current date.
According to the journal
nov. 03 18:16:44 osmc blkmapd[279]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory
nov. 03 18:16:44 osmc systemd[1]: Started pNFS block layout mapping daemon.
mars 27 08:15:41 osmc fake-hwclock[228]: mardi 27 mars 2018, 06:15:41 (UTC+0000)
mars 27 08:15:41 osmc systemd[1]: Time has been changed
mars 27 08:15:41 osmc systemd[1]: Started Restore / save the current clock.
mars 27 08:15:41 osmc systemd[1]: Started Set the console keyboard layout.
fake-hwclock is called at the end of the boot sequence, but what is the date used during boot?
I thought that fake-hwclock was set to avoid this

jsaldivias
Posts: 13
Joined: Mon Mar 06, 2017 8:49 pm

Re: fake-hwclock time adjustment

Thu Jun 07, 2018 7:20 pm

This worked fine for me. Thanks for the tip.

Return to “Beginners”