System time is always wrong after reboot

tk83 · January 6, 2011, 4:14pm

Every time I reboot my computer the system time always comes up exactly 10 hours behind where it should be. So if I reboot it at 16:00 it comes up as 06:00.

This has only been happening since I got back from a trip to Australia, where I naturally changed the computer’s timezone to match the local one. I’m now back in Central European Time which is 10 hours behind Australia’s. This is on opensuse 11.3.

I’ve used the YAST date and time tool to set the timezone correctly, and /etc/localtime is set correctly:

:~> sha1sum /etc/localtime
b065fae6bda0f0642ca6a52b665768e34a99d213  /etc/localtime
:~> sha1sum /usr/share/zoneinfo/Europe/Berlin 
b065fae6bda0f0642ca6a52b665768e34a99d213  /usr/share/zoneinfo/Europe/Berlin

The hardware clock is set correctly (I’ve had to manually restart ntp here to get date to show the correct time):

sudo hwclock --show; date
Do 06 Jan 2011 16:13:20 CET  -0.375604 Sekunden
Do 6. Jan 16:13:20 CET 2011

I don’t understand what the problem is.

hcvv · January 6, 2011, 5:19pm

Do you have a multiboot system with an MS Windows as partner? And what did you choose in YaST fore the setting: Set hardware clock to GMT/Local time?

tsu2 · January 6, 2011, 7:36pm

You might find a thread I started a few months ago interesting

Which NTP client is preferred?

It can get very confusing the more you think about the numerous possible combinations of configurations.

In addition to what was posted there, you might also consider the “chicken or egg” quandry… What you’re seeing now could also be influenced by what you did to set time when in Australia, not just what you are doing now.

Proabably the bottom line recommendation:
Using the YAST tool, configure time to be set by connecting to a Timeserver, not the local system settings. Then, keep an eye out for any higher level modifications. Of course, you’ll need a working network connection to connect to a Timeserver.

IMO,
Tony

john_hudson · January 6, 2011, 7:42pm

If you have Windows on the computer, you need to leave Windows to handle the hardware clock; if you only have Linux, set the hardware clock to UTC and then go to YaST>System>Date and time. Set the hardware clock to UTC and set your timezone.

tk83 · January 6, 2011, 7:52pm

Yes, I have Windows 7 on this laptop also. In the first reboot after I got back to Germany Windows 7 had the same problem - clock 10 hours behind, but after I set the clock properly (in Windows) Windows doesn’t have this problem anymore.

I don’t think Windows is the cause of the problem in Linux either, since the problem occurs when I reboot from Linux back into Linux, with no loading of Windows inbetween.

And what did you choose in YaST fore the setting: Set hardware clock to GMT/Local time?

Where is this in the YAST GUI - I can’t see it in the ‘Date and Time’ module? I do however have hardware clock set to local time in /etc/sysconfig/clock. I’ve also manually applied this setting (hwclock --localtime) a couple of times to see if this makes a difference, but so far no luck.

My /etc/sysconfig/clock:

## Path:                System/Environment/Clock
## Description:         Information about your timezone and time
## Type:                string(-u,--utc,--localtime)
## ServiceRestart:      boot.clock
## Command:             /sbin/refresh_initrd
#
# Set to "-u" if your system clock is set to UTC, and to "--localtime"
# if your clock runs that way.
#
HWCLOCK="--localtime"
## Description: Write back system time to the hardware clock
## Type:                yesno
## Default:             yes
#
# Is set to "yes" write back the system time to the hardware
# clock at reboot or shutdown. Usefull if hardware clock is
# much more inaccurate than system clock.  Set to "no" if
# system time does it wrong due e.g. missed timer interrupts.
# If set to "no" the hardware clock adjust feature is also
# skipped because it is rather useless without writing back
# the system time to the hardware clock.
#
SYSTOHC="yes"

## Type:                string(Europe/Berlin,Europe/London,Europe/Paris)
## ServiceRestart:      boot.clock
#
# Timezone (e.g. CET or Asia/Tokyo). The value should correspond
# to the contents of the /etc/localtime file and is for internal
# YaST use; changing this setting will not make SuSEconfig update
# the /etc/localtime file, YaST does that or you will need to do
# this manually by calling zic -l.
#
TIMEZONE="Europe/Berlin"
DEFAULT_TIMEZONE="US/Eastern"

I don’t understand why the problem occurs, as when I check the time in the BIOS setup screens as the system reboots the clock there is always correct. It’s just Linux that’s for some reason setting itself back 10 hours from this correct time.

nrickert · January 6, 2011, 8:16pm

In Windows, set the time zone to GMT (or UTC).

Then follow the suggestions here: Set hardware clock to UTC on Windows (or how to make the clock work on a Mac Book Pro) - David Findley’s Blog

Then change Windows to use the timezone that you want. The effect is that the hardware clock will now remain at UTC (or GMT), no matter what timezone you use. This seems to work fine with Vista and Windows 7, but is a bit iffy with XP.

Back in your linux system, use Yast to set the hardware clock to GMT.

You might have to resynchronize with a time server. But, after that, you should not have future timezone problems.

hcvv · January 6, 2011, 8:20pm

YaST > System > Date and Time. It is the checkbox lower left that says something like: set hardware clock to UTC (I called it GMT, buit that is the same for our purpose).

I warn you that the thread tsu2 points to is interesting but confusing. In some places the difference between the setting of the Linux system time (at boot from the hardware clock and as soon as the network is up correcting it using NTP) to UTC (which is the time used by all Unix//Linux systems) and the setting of a time zone for a user (to make him/her see in his/her session a time translated to his/her wanted timezone) is often blurred there.

please_try_again · January 6, 2011, 9:17pm

Yes. This has been - and probably still is - the easiest and most reasonnable solution for many years. If there is a way (as mentionned by nrickert in his post) to force Windows to use UTC, that would probably be better. On the other hand, notice that Ubuntu now defaults to localtime and do not give you another choice during setup! openSUSE still behaves like Unix regarding time … but for how much longer?

robin_listas · January 6, 2011, 9:50pm

On 2011-01-06 20:06, tk83 wrote:
>

starting note: you should, or might, have changed the time, during the trip
and later, only for the user. This is done in the desktop, or in console
(not as root).

> hcvv;2274496 Wrote:
>> Do you have a multiboot system with an MS Windows as partner?
>
> Yes, I have Windows 7 on this laptop also. In the first reboot after I
> got back to Germany Windows 7 had the same problem - clock 10 hours
> behind, but after I set the clock properly (in Windows) Windows doesn’t
> have this problem anymore.

Ok, good.

> I don’t think Windows is the cause of the problem in Linux either,
> since the problem occurs when I reboot from Linux back into Linux, with
> no loading of Windows inbetween.

Yes, and no. It has some influence. I’ll explain later.

>> And what did you choose in YaST fore the setting: Set hardware clock to
>> GMT/Local time?
>
> Where is this in the YAST GUI - I can’t see it in the ‘Date and Time’
> module?

A click box.

> I do however have hardware clock set to local time in
> /etc/sysconfig/clock.

That’s the same thing.

> I’ve also manually applied this setting (hwclock
> --localtime) a couple of times to see if this makes a difference, but so
> far no luck.

Good. You are near the mark, but you need something else.

>
> My /etc/sysconfig/clock:
>
> Code:
> --------------------
> --------------------

Good.

> I don’t understand why the problem occurs, as when I check the time in
> the BIOS setup screens as the system reboots the clock there is always
> correct. It’s just Linux that’s for some reason setting itself back 10
> hours from this correct time.

I think I do >:-)

Ok, get the clock to display correctly your preferred way. Check that root
has the correct time setting by using, in a terminal, the command “date”.
Check that the cmos clock is correct by using hwclock.

And then, the untold trick: delete “/etc/adjtime”!

This file has saved that you once shifted the clock 10 hours, and is
replaying the change on each boot. This is what it is for, it is thinking
that your clock is too fast or slow, and adjusting automatically for it.

So, delete that file, then redo the hwclock --localtime --systohc command
to set the cmos clock and recreate the adjtime correctly.

HTH.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

robin_listas · January 6, 2011, 10:03pm

On 2011-01-06 21:36, please try again wrote:

> On the other hand, notice that Ubuntu now defaults to
> localtime and do not give you another choice during setup! openSUSE
> still behaves like Unix regarding time … but for how much longer?

For ever

I think that the Ubuntu way only affects the cmos clock and how the system
clock is initialized - ie, boot scripts. Once the system is running, the
method is unchanged, it depends on the kernel, which keeps UTC time⁽¹⁾. And
Ubuntu can’t change that much the kernel

(1) Well, not really UTC, but it close enough

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

please_try_again · January 6, 2011, 10:41pm

Well … Ubuntu does change CMOS time (UTC) every time I install it. It interprets the time as localtime and reset the CMOS time … anyway, things are that the time is always wrong after an Ubuntu install and I end up with files which have a timestamp in the future.

Then it is uncomplicated to tell Ubuntu to use UTC for init scripts. But you have to install it first. And unlike openSUSE’s setup (which let you check either UTC or locatime) during setup, Ubuntu knows only locatime at this point.

user · January 7, 2011, 3:09am

On 2011-01-06 23:06, please try again wrote:
>
> robin_listas;2274677 Wrote:

> Well … Ubuntu does change CMOS time (UTC) every time I install it. It
> interprets the time as localtime and reset the CMOS time … anyway,
> things are that the time is always wrong after an Ubuntu install and I
> end up with files which have a timestamp in the future.

Well, if you double boot to ubuntu you will have to play their way and leave the cmos clock as local
time, suse will play along just fine - it is not a problem unless you travel time zones.

> Then it is uncomplicated to tell Ubuntu to use UTC for init scripts.
> But you have to install it first. And unlike openSUSE’s setup (which let
> you check either UTC or locatime) during setup, Ubuntu knows only
> locatime at this point.

It is complicated - if their scripts are only designed for local time, you have to create new
scripts to handle UTC yourself. Perhaps somebody there knows about this. I know nothing about ubuntu
insides, I can’t recomend you anything, but I guess it is easier to play along and let it have its way.

Don’t they say ubuntu is easier? It imitates Windows in this as well >:-P

I read some where that customizing Ubuntu, beyond a certain point, is really hard. Dunno.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Minas Tirith))

tk83 · January 9, 2011, 4:00pm

Thanks for all the responses, I tried them but it didn’t help.

I did some more digging and found that when I ran the boot.clock script manually (sudo /etc/init.d/boot.clock start), it was saying that it had worked successfully but the date command revealed it had in fact done nothing.

Since this script AFAIK is what sets the system time to the hardware clock time on boot-up I thought it might be a bug in the kernel I was using, which is from the Tumbleweed project. Sure enough, I installed the kernel-vanilla package and rebooted - the time was set correctly.

I’ve resolved the problem by re-enabling the Tumbleweed repository and updating to the latest kernel from there, it looks like the Tumbleweed developers have fixed the bug

robin_listas · January 9, 2011, 8:05pm

On 2011-01-09 16:06, tk83 wrote:
> Since this script AFAIK is what sets the system time to the hardware
> clock time on boot-up I thought it might be a bug in the kernel I was
> using, which is from the Tumbleweed project. Sure enough, I installed
> the kernel-vanilla package and rebooted - the time was set correctly.
>

Curious!

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Minas Tirith))

smowton · February 5, 2012, 8:08am

Resurrecting this thread because I fixed this problem, and this is the top hit on Google for this predictably errant system clock problem.

I fixed it by:

Deleting /etc/adjtime as suggested by one of the posters here. In particular I notice /etc/init.d/boot.clock consults its 3rd line which was “UTC”, whereas after the file was recreated it was “LOCAL”.
Because the clock boot script is run very early, I ran mkinitrd. After this second step it worked; I’m not sure but I suspect this is because some of these /etc/ time-related files are packaged in the initrd for pre-localfs scripts to consume. The first step may not have been necessary, but since it explicitly misrepresented my hardware clock setup, and boot.clock function “adjtime_thirdline” reads it, it was likely to be causing trouble.

If you’re having this problem, it would be good if you could pin down the exact cause – first try just mkinitrd and see if that works. Then try just removing /etc/adjtime. Then finally mkinitrd once more.

smowton · February 6, 2012, 8:31am

In fact, see here for a clear explanation as to why mkinitrd was necessary: https://bugzilla.novell.com/show_bug.cgi?id=627116

I’m using OpenSuSE 11.4, but I suspect my problem was caused by the fact that I hadn’t changed my default timezone using YaST, which that patch upgraded, but the GNOME clock utility.

please_try_again · February 6, 2012, 8:58am

And if you multi boot with NetBSD and openBSD, what would you recommend?

You set UTC=‘yes’ in /etc/default/rcS. That’s it. The only problem is that the option is missing in the oversimplified GUI setup. When you reboot it’s too late (or to early, depending where you live) , unless you call the BIOS setup.

I know nothing about ubuntu insides, I can’t recomend you anything

Then don’t! … for a change, lol!

Don’t they say ubuntu is easier?

It is not.

It imitates Windows in this as well >:-P

So does openSUSE with its evil generic MBR. Well… 15 love!

I read some where that customizing Ubuntu, beyond a certain point, is really hard. Dunno.

*Mit Geduld und Spucke, faengt man eine Muecke. *
Google Translate: With patience and saliva, you are starting a mosquito. lol!

robin_listas · February 6, 2012, 11:48am

On 2012-02-06 09:06, please try again wrote:
>
> Carlos E. R.;2274782 Wrote:

This is a year old. Did you notice?

> And if you multi boot with NetBSD and openBSD, what would you
> recommend?

I don’t. They are not Linux.

> Carlos E. R.;2274782 Wrote:

>> It is complicated - if their scripts are only designed for local time,
>> you have to create new scripts to handle UTC yourself. Perhaps somebody there knows about
>> this.
>>
>
> You set UTC=‘yes’ in /etc/default/rcS. That’s it. The only problem is
> that the option is missing in the oversimplified GUI setup. When you
> reboot it’s too late (or to early, depending where you live) , unless
> you call the BIOS setup.

Thanks for explaining.

>> I know nothing about ubuntu insides, I can’t recomend you anything
>
> Then don’t! … for a change, lol!

And I did not. I gave my opinion.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

robin_listas · February 6, 2012, 12:08pm

On 2012-02-05 08:16, smowton wrote:
>
> Resurrecting this thread because I fixed this problem, and this is the
> top hit on Google for this predictably errant system clock problem.

Thank you. Your post clarifies some problems.

> I fixed it by:
>
> 1. Deleting /etc/adjtime as suggested by one of the posters here.

Yes, I think I did. But seeing your post, I was at fault for not telling
you how to recreate the file with the appropriate utc/local setting. And
maybe even that would not have been enough, dunno.

> In
> particular I notice /etc/init.d/boot.clock consults its 3rd line which
> was “UTC”, whereas after the file was recreated it was “LOCAL”.
> 2. Because the clock boot script is run very early, I ran mkinitrd.
> After this second step it worked; I’m not sure but I suspect this is
> because some of these /etc/ time-related files are packaged in the
> initrd for pre-localfs scripts to consume. The first step may not have
> been necessary, but since it explicitly misrepresented my hardware clock
> setup, and boot.clock function “adjtime_thirdline” reads it, it was
> likely to be causing trouble.

You can have a look inside that file, it is a …cpio.gz archive. I did
that just now and it contains:


/bin/warpclock
/boot/05-clock.sh
/etc/sysconfig/clock

That last file contains, in my case, a single line:


HWCLOCK="-u"

which is a setting for UTC. The 05-clock.sh uses it.

> If you’re having this problem, it would be good if you could pin down
> the exact cause – first try just mkinitrd and see if that works. Then
> try just removing /etc/adjtime. Then finally mkinitrd once more.

If you change the setting from utc to local or the other way round, then
you have to recreate initrd, I can see that. More I dunno.

And the adjtime file can be re-created with the appropiate line, which was
your problem. Previously, this file was properly recreated on system
power-down, but maybe this has changed.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

robin_listas · February 6, 2012, 12:08pm

On 2012-02-06 08:36, smowton wrote:
>
> In fact, see here for a clear explanation as to why mkinitrd was
> necessary: https://bugzilla.novell.com/show_bug.cgi?id=627116
>
> I’m using OpenSuSE 11.4, but I suspect my problem was caused by the
> fact that I hadn’t changed my default timezone using YaST, which that
> patch upgraded, but the GNOME clock utility.

It would be interesting to ascertain if yast recreates initrd on this change.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)