System clock - [Solved]

Arch based Porteus community project

Moderator: M. Eerie

roadie
Full of knowledge
Full of knowledge
Posts: 400
Joined: 02 Jan 2011, 18:41
Distribution: Porteus 5.0-RC1
Location: In a hayfield

Re: System clock - not solved

Post#16 by roadie » 04 Dec 2015, 19:15

@Ed_P

If you're dual booting Windows, this may apply....from the Arch wiki.


Recommended: Set both Arch Linux and Windows to use UTC, following Time#UTC in Windows. Also, be sure to prevent Windows from synchronizing the time on-line, because the hardware clock will default back to localtime.

Not recommended: Set Arch Linux to localtime and disable any time-related services, like NTPd . This will let Windows take care of hardware clock corrections and you will need to remember to boot into Windows at least two times a year (in Spring and Autumn) when DST kicks in. So please do not ask on the forums why the clock is one hour behind or ahead if you usually go for days or weeks without booting into Windows.


I've set all my installs to the same settings and time is working well.

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: System clock - not solved

Post#17 by brokenman » 04 Dec 2015, 19:36

But even with the time zone wrong I don't think the OS should change the machine's clock without user involvement.
i agree, especially a portable OS ...
This is standard operating procedure for most operating systems. The problem comes along with which operating system you think is doing it right. I frequently experience this when I travel across timezones.

Here is how it works:
Your computer has two clocks. An onboard hardware clock (CMOS) and a system (software) clock. You can see both by issuing as root: timedatectl
The hardware clock just stores numbers. It has no concept of time standards like localtime or UTC. Therefore, when the system boots the OS reads the hardware clock, makes some changes based on your timezone and stores this in the system clock until shutdown, at which time it writes back to the hardware clock. Windows uses localtime by default while MAC and most linux like OSs use UTC.

Dual boot setups can cause problems because both OSs derive their time from the same hardware clock. If they are both using different standards (oxymoron I know) then one writes back to the hwclock on shutdown, and then the other OS writes a different time back to the hwclock, and all hell breaks loose and time travel almost becomes possible. The trick is to ensure that all OSs see the hardware clock as providing time in the same chosen standard. This is much easier than trying to tell the OS designers not to write to the hwclock.

I recommend roadies advice.

EDIT:
In order to justify my statement about designers not writing to the hardware clock consider this. Your computer probably doesn't have an atomic clock installed. Most computer clocks are not so good at keeping time. They can drift up to a few minutes every week. This would be chaotic for log systems (among other things), so most OSs will prevent this drift by writing back to the hwclock.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: System clock - not solved

Post#18 by Ahau » 04 Dec 2015, 20:15

From the computer's standpoint, time travel actual does occur! I recall one time I downloaded sources to compile XFCE immediately after they were released. I was unable to compile the sources because the files were timestamped, from my system's standpoint, in the future! IIRC, GCC spit out a ton of horrendous error messages. The sources had been packaged by someone using UTC time on their system (no surprise there), and located halfway around the world (to the East, where it was late at night). My system thought it was earlier that same day because I was on localtime, which, without a timezone set, would be associated as GMT. There was probably an easy way to get around it, but I just waited several hours before I compiled it.
Please take a look at our online documentation, here. Suggestions are welcome!

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: System clock - not solved

Post#19 by brokenman » 04 Dec 2015, 20:26

I was unable to compile the sources because the files were timestamped, from my system's standpoint, in the future!
This happens to me all the time in git repositories.

Code: Select all

find /path/to/source -type f | xargs touch
To fix this problem Ed_P try the following:

Code: Select all

# Sync system time with online server
ntpd -qg
# Write this time to hardware clock and set it to utc
hwclock --systohc --utc
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
Ed_P
Contributor
Contributor
Posts: 8341
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Re: System clock - not solved

Post#20 by Ed_P » 04 Dec 2015, 21:36

Holy Cow!! Lots of suggestions.
Ahau wrote:What other OS's are you running? If it's Porteus, are you running with a timezone set?
Porteus 3.0.1, Windows 10, sometimes Porteus 3.1.
Does the clock continue to advance 5 hours on every subsequent boot of Nemesis, i.e. it's Noon in New York, you boot into Nemesis and your clock says it's 5pm; then you reboot into Porteus and it shows 5pm, then you boot back into Nemesis and it's 10pm? or is it consistently 5 hours ahead?
hmmmm An interesting question. Normally when I boot into an OS with the wrong time I correct it so don't know if Nemesis would continue it's clock shifting repeatedly.
For both Nemesis and standard Porteus (without altering your settings or your clock time from where they are now), can you please give the output of:

Code: Select all

date
date -u
OK. This is from Nemesis (which has a .profile file)

Code: Select all

guest ~ $ date
Fri Dec  4 16:32:01 EST 2015
guest ~ $ date -u
Fri Dec  4 21:32:18 UTC 2015
guest ~ $ 
An interesting thought, how did Nemesis know my system clock wasn't UTC and how did it know to advance it 5 hrs, rather than 4 or 6 or -5?

- update -
roadie wrote:I've set all my installs to the same settings and time is working well.
I considered doing something like that but since this is the 1st system to cause this problem I think fixing the cause is the better approach.

- update -
brokenman wrote:To fix this problem Ed_P try the following:

Code: Select all

# Sync system time with online server
ntpd -qg
# Write this time to hardware clock and set it to utc
hwclock --systohc --utc

Yes, but then I would have to change the various OSs I run to work with the system clock as UTC. And while this could work it wouldn't work with this system running on my USB drive which can run on other machines. I can't see leaving notes to people that my USB drive screwed up thier system's clock, Sorry.
Ed

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: System clock - not solved

Post#21 by brokenman » 04 Dec 2015, 22:33

I considered doing something like that but since this is the 1st system to cause this problem I think fixing the cause is the better approach.
Ah, we just explained the cause and how to fix it.
Normally when I boot into an OS with the wrong time I correct it
Didn't you just say "is the 1st system to cause this problem"?
Yes, but then I would have to change the various OSs I run to work with the system clock as UTC.
You can always do the reverse ... but you are going to have to change some system somewhere. Your choice. If you search for this stuff you will find that it is one of the most common questions ask on linux forums. Another option is to stop systemd from writing anything to the hardware clock on shutdown. I am not on Nemesis at the moment but have a look for a file /etc/conf.d/hwclock which may allow you to follow this method.

Good luck
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
Ed_P
Contributor
Contributor
Posts: 8341
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Re: System clock - not solved

Post#22 by Ed_P » 04 Dec 2015, 22:45

brokenman wrote:
Normally when I boot into an OS with the wrong time I correct it
Didn't you just say "is the 1st system to cause this problem"?
Yes, and it is. The others are machines that have been unplugged for extended periods of time and their cmos batteries are dead.
You can always do the reverse ... but you are going to have to change some system somewhere. Your choice.
And my choice is this one, or else. :twisted:
I am not on Nemesis at the moment but have a look for a file /etc/conf.d/hwclock which may allow you to follow this method.
Me either but I will look when I get back in a couple of minutes.
Last edited by Ed_P on 04 Dec 2015, 22:55, edited 1 time in total.
Ed

User avatar
Ed_P
Contributor
Contributor
Posts: 8341
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Re: System clock - not solved

Post#23 by Ed_P » 04 Dec 2015, 22:48

Ahau wrote:

Code: Select all

date
date -u
Porteus 3.0.1 - after booting Nemesis and Porteus a couple of times with no manual time changes.

Code: Select all

guest@porteus:~$ date
Fri Dec  4 22:44:24 EST 2015
guest@porteus:~$ date -u
Sat Dec  5 03:44:28 UTC 2015
guest@porteus:~$ 
Actual time here is 5:45 pm EST

Nemesis again

Code: Select all

guest ~ $ date
Fri Dec  4 17:49:21 EST 2015
guest ~ $ date -u
Fri Dec  4 22:49:28 UTC 2015
guest ~ $ 
Ed

User avatar
Ed_P
Contributor
Contributor
Posts: 8341
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Re: System clock - not solved

Post#24 by Ed_P » 04 Dec 2015, 23:15

brokenman wrote:have a look for a file /etc/conf.d/hwclock which may allow you to follow this method.

Code: Select all

guest ~ $ cat /etc/conf.d/hwclock
cat: /etc/conf.d/hwclock: No such file or directory
guest ~ $ cat /etc/conf.d/hwclock                <--- copy & pasted from your posting  :-)
cat: /etc/conf.d/hwclock: No such file or directory
guest ~ $ ls /etc/conf.d/
rngd
guest ~ $ 
Interesting, I didn't have this problem running Porteus 2.1, or Porteus 3.0, or Porteus 3.0.1, or Porteus 3.1, or even Porteus Kiosk. Whatever fix you had in those releases to prevent this clock update problem can't it be added to Porteus 3.3? i.e. "ensure that all OSs see the hardware clock as providing time in the same chosen standard. " :)
Ed

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: System clock - not solved

Post#25 by brokenman » 04 Dec 2015, 23:24

Yes. I will look into removing any write to the hardware clock for default, and offer the option to turn it back on in the first run wizard. Thanks for testing.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: System clock - not solved

Post#26 by Ahau » 04 Dec 2015, 23:26

Ed,

In standard Porteus, please look at /etc/hardwareclock

If the uncommented line is "localtime" then your Porteus install is not correctly configured. You should only use a timezone if your /etc/hardwareclock is set to UTC. I suspect that is what is going on based on the date outputs you gave.

I use localtime, no timezone, and set my hardware clock to match my current local time. This works in Porteus, Windows and Nemesis out of the box. UTC is more appropriate for *nix systems but I have Windows on this machine and I don't have administrative priveleges to change how Windows keeps time.

You can try the time config utility in Porteus Settings Center to configure standard Porteus either way you choose. I don't think it will work with Nemesis without modification for systemd commands.
Please take a look at our online documentation, here. Suggestions are welcome!

User avatar
Ed_P
Contributor
Contributor
Posts: 8341
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Re: System clock - not solved

Post#27 by Ed_P » 04 Dec 2015, 23:50

This is what I use in standard Porteus.

Image

And this is what the /etc/hardwareclock file has.

Code: Select all

# /etc/hardwareclock
#
# Tells how the hardware clock time is stored.
# You should run timeconfig to edit this file.

localtime
Ed

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: System clock - not solved

Post#28 by Ahau » 05 Dec 2015, 00:19

Select UTC there and Porteus will then match up with Nemesis (as configured with timezone in your .profile)

You should not be allowed to select both localtime and a timezone, I thought I wrote it such that the time zones were greyed out when localtime was selected. I'll look into that next time I can log in to Porteus.
Please take a look at our online documentation, here. Suggestions are welcome!

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: System clock - not solved

Post#29 by brokenman » 05 Dec 2015, 01:05

From what I can see, Porteus v3.1 checks /etc/hardwareclock for the string 'UTC' upon boot. If found then it sets the system clock as UTC. If not it sets the system clock as localtime. On shutdown there is nothing written to the hardware clock.

Which sounds better?

1a) Set Porteus to localtime by default
1b) Set Porteus to UTC by default

2a) Only update hardware clock on shutdown when booting Porteus from fixed drive.
2b) Never update hardware clock
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
Ed_P
Contributor
Contributor
Posts: 8341
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 5.01 ISO
Location: Western NY, USA

Re: System clock - not solved

Post#30 by Ed_P » 05 Dec 2015, 04:31

brokenman wrote:From what I can see, Porteus v3.1 checks /etc/hardwareclock for the string 'UTC' upon boot. If found then it sets the system clock as UTC. If not it sets the system clock as localtime. On shutdown there is nothing written to the hardware clock.
My Porteus 3.0 file.

Code: Select all

guest@porteus:~$ su
Password: 
root@porteus:/home/guest# cat /etc/hardwareclock
# /etc/hardwareclock
#
# Tells how the hardware clock time is stored.
# You should run timeconfig to edit this file.

localtime
root@porteus:/home/guest# 
My Porteus 3.1 file.

Code: Select all

guest@porteus:~$ cat /etc/harewareclock
cat: /etc/harewareclock: No such file or directory
guest@porteus:~$ su
Password: 
root@porteus:/home/guest# cat /etc/hardwareclock
# /etc/hardwareclock
#
# Tells how the hardware clock time is stored.
# You should run timeconfig to edit this file.

localtime
root@porteus:/home/guest# 
Which sounds better?

1a) Set Porteus to localtime by default
1b) Set Porteus to UTC by default

2a) Only update hardware clock on shutdown when booting Porteus from fixed drive.
2b) Never update hardware clock
IMO Personally I like 1.a :) especially if Porteus is hoping to appeal to Windows users, which I think it does an excellent job of doing. With 2 I recommend 2b unless booting from a fixed disk install.

Basically if booting from an ISO don't change the machine regardless if booting from a USB drive or a hard drive/fixed drive. An ISO boot is a temporary "install" regardless of media. But support a user's need/desire/wish to set a timezone and remember it if booting from an ISO or a USB drive.

Ok?
Ed

Post Reply