System time / hwclock mismatch, must manual fsck each boot

rasteenb · 2009-10-04 18:16:29

Greetings:
My system clock is perpetually 5 hours behind the hw clock.
The hw clock is on local time and the GMT offset is 5 hours, although the system clock shows the wrong time as CDT, not GMT.

I have attempted to fix it by:
manually setting the date
removing the /etc/localtime file
by changing the permissions & users on the /etc/localtime file
by including the openntpd daemon on startup

No luck. After correcting the system time, if I shut down my laptop and reboot later, it tells me that the Superblock time is in the future and forces me to manually fsck to stamp the Superblock with the [incorrect] time.
This is not fun.
For awhile the problem would be automatically fixed (to the incorrect time) at boot, but now I am being forced to fix it myself.

None of the techniques I've found in the forums so far have worked.
A possible clue:
When I reboot after fsck-ing, a message flashes by about a problem writing "/etc/localtime" because of a permission. I've tried change the permissions and the owner/group (666 and users:users) but this didn't seem to help.

Any suggestions? I'm running an Acer Aspire One 150, boots XP and Ubuntu from the hard drive and Arch from a USB stick. I haven't used XP in a long time.

Rob

brenix · 2009-10-04 18:59:37

Hmm, if you take a look at the /etc/rc.sysinit around line 299 (default rc.sysinit), you can see the commands taking place when it adjusts the system clock. This may help find where the issue exists as you can run through each one and see where a problem comes up.. Just a thought..

Nepherte · 2009-10-04 20:00:23

I had this exact problem yesterday myself. I've also seen someone else with the isue as well. To solve the booting problem, using the hwclock command worked. I believe i ran

hwclock -s

I've also tried various things to solve "the core problem" but none so far helped. I first verified my settings were correct: timezone and the way the time is stored in bios (localtime because I occasionally run windows as well). I also used openntpd to sync with time servers. I've put it in the DAEMONS array but it doesn't set the time correctly after it has reached the login screen. Only after restarting the service, the correct time is set. I now tried some other thing that might solve it, but I'm not sure yet. Hell, it might even be the bios battery but it's barely 2 years old.

loafer · 2009-10-04 20:05:52

Is the hardware clock in /etc/rc.conf defintetely set to localtime?

Nepherte · 2009-10-05 13:20:12

Positive:

...
LOCALE="nl_BE.utf8"
HARDWARECLOCK="localtime"
TIMEZONE="Europe/Brussels"
KEYMAP="be-latin1"
...

For now I'm not experiencing the problem anymore after removing /var/lib/hwclock/adjtime. Perhaps it might help rasteenb as well.

Dieter · 2009-10-05 13:27:54

I have the same problem on my box running Arch x86_64 (I don't know whether this is a 64-bit only issue). HARDWARECLOCK is (definitely) set to "localtime" and TIMEZONE is "Europe/Berlin" here. At boot time I often receive "superblock last mount time is in the future" message. The date command shows UTC time with "CEST" which is wrong; I expected local time with CEST (Central European summer time) or at least UTC without CEST. It seems that "localtime" and/or timezone(s) are ignored during boot before file system check starts.
http://bbs.archlinux.org/viewtopic.php?id=81444 seems to deal with the same issue.

Last edited by Dieter (2009-10-05 13:30:45)

lpb331 · 2009-10-05 14:11:43

I had a similar problem a couple months ago. I finally noticed that I was passing different options to the hwclock command on shutdown than on startup. So when I shutdown, the clock was reset to localtime in the rc.shutdown script. Then when I started up, since I was using UTC (5 hrs ahead of me), the clock was then set to the same time in my time zone since hwclock is called twice in the rc.sysinit script. If I restarted within a few hours, I got the message about the superblock being set in the future. Hope this helps!

Harey · 2009-10-09 10:06:25

There seems to be a bug in timezone handling by the current initscripts.
I have two systems with identical hardware and software installed. Both are 32 bit and in use as servers without X. Both of them have openntpd running and synchronize time to de.ntp.pool.org. Since a short Period one of them hung during booting with a filesystem error "superblock last mount time is in the future". I tried to find the difference between the two of them and found that a recent pacman -Syu must have introduced the error. Since the installed software is basically the same and the update was applied to both of them I guessed that there must be a difference in the configuration files. At last I found a difference in the file rc.conf which I missed to update on one server. This is the one that does not hang during boot.
It reads:

LOCALE="de_DE.utf8"                                                         
HARDWARECLOCK="local"                                                   
TIMEZONE="Europe/Berlin"

Which is incorrect according to the new rc.conf template. The other one reads

LOCALE="de_DE.utf8"                                                         
HARDWARECLOCK="localtime"                                                   
TIMEZONE="Europe/Berlin"

which should be correct. Notice the difference in HARDWARECLOCK. Well, this one hangs during boot. I checked hardware clocks on both of them. They are both set to localtime.
As a proof I set the second one to "local" as well and it booted properly.
rc.conf says

# HARDWARECLOCK: set to "UTC" or "localtime", any other value will result
# in the hardware clock being left untouched (useful for virtualization)

Since this comment changed in the new rc.conf I guess there has been some tweaking her that leads to trouble.

shining · 2009-10-09 12:03:44

Harey wrote:

Since this comment changed in the new rc.conf I guess there has been some tweaking her that leads to trouble.

I am a bit confused by your comment.

After you changed local to localtime, is everything fine now ?

Harey · 2009-10-09 12:27:17

shining wrote:

After you changed local to localtime, is everything fine now ?

No, it's just the other way round. If I change to localtime (which should be the correct setting) the system hangs. According to the comment in rc.conf anything else then HARDWARECLOCK="UTC" should leave the hardware clock untouched. This does not seem to be correct. 'local' is not a valid keyword anymore, I could as well write "hrmpf" and it should be ignored...

I guess the use of "localtime" triggers some weird behaviour from the initscripts.

Harvey

VuDu · 2009-10-15 18:13:26

Harey wrote:

There seems to be a bug in timezone handling by the current initscripts.
I have two systems with identical hardware and software installed. Both are 32 bit and in use as servers without X. Both of them have openntpd running and synchronize time to de.ntp.pool.org. Since a short Period one of them hung during booting with a filesystem error "superblock last mount time is in the future". I tried to find the difference between the two of them and found that a recent pacman -Syu must have introduced the error. Since the installed software is basically the same and the update was applied to both of them I guessed that there must be a difference in the configuration files. At last I found a difference in the file rc.conf which I missed to update on one server. This is the one that does not hang during boot.
It reads:
LOCALE="de_DE.utf8"                                                         
HARDWARECLOCK="local"                                                   
TIMEZONE="Europe/Berlin"
Which is incorrect according to the new rc.conf template. The other one reads
LOCALE="de_DE.utf8"                                                         
HARDWARECLOCK="localtime"                                                   
TIMEZONE="Europe/Berlin"
which should be correct. Notice the difference in HARDWARECLOCK. Well, this one hangs during boot. I checked hardware clocks on both of them. They are both set to localtime.
As a proof I set the second one to "local" as well and it booted properly.
rc.conf says
# HARDWARECLOCK: set to "UTC" or "localtime", any other value will result
# in the hardware clock being left untouched (useful for virtualization)
Since this comment changed in the new rc.conf I guess there has been some tweaking her that leads to trouble.

Thanks! I was having the same problem and that did it for me (changing local to localtime).

Harey · 2009-10-15 20:19:23

Vudu,

Thanks! I was having the same problem and that did it for me (changing local to localtime).

Unfortunately it did not work for me this way because of openntpd. When openntpd is invoked the system seems to think it is on utc even when timezone is right and HARDWARECLOCK="localtime" is set. This leads to "superblock last mount time is in the future"-error although everything should be right. The only way out is to set the hardwareclock to UTC and HARDWARECLOCK="UTC" in /etc/rc.conf. This is not related to x86_64 because yesterday i had a box on arch i686 with the same error...

There seems to be an error somewhere in intscripts or openntpd.

Harvey

cleanrock · 2009-10-31 09:18:49

I also experienced this problem lately.
My hw clock is set incorrectly at boot (i see it is ok in bios before boot).
I am using "localtime" and openntpd.
I think the problem is the recent DST shift and the /sbin/hwclock --adjust in /etc/rc.sysinit.
Deleting /var/lib/hwclock/adjtime should fix this but i suspect the problem will popup again with next DST shift.

rasteenb · 2009-11-01 13:28:21

I replaced

"local" with

"localtime"

in my rc.conf and now the system clock and hw clock are in agreement the Superblock times work.

Note: I had turned off Openntpd awhile ago in my attempts to fix this problem. I did an

ntpd -d -s

to get my system back on the right time.

Thanks for the fix!

Rob

bernarcher · 2009-11-01 18:30:08

cleanrock wrote:

I also experienced this problem lately.
My hw clock is set incorrectly at boot (i see it is ok in bios before boot).
I am using "localtime" and openntpd.
I think the problem is the recent DST shift and the /sbin/hwclock --adjust in /etc/rc.sysinit.
Deleting /var/lib/hwclock/adjtime should fix this but i suspect the problem will popup again with next DST shift.

Quite possible so because using localtime the hardware clock will be set to a new value on DST shifts. This is other than with UTC where the hardwareclock remains unaffected and the system time will be adjusted by software only.

Quoting from the TIMEZONE wiki:

IMPORTANT: When the HARDWARECLOCK setting is set to localtime, Linux will not adjust the time, operating under the assumption that your system may be a dual boot system at that time and that the other OS takes care of the DST switch. If that was not the case, the DST change needs to be made manually.

Thus it would be a good idea to delete adjtime after a DST shift if using localtime.

cleanrock · 2009-11-02 13:28:20

I switched to UTC time, it works dual booting with Windows if you set RealTimeIsUniversal in Windows registry. (google for RealTimeIsUniversal if you are interested)

manouchk · 2009-11-29 13:28:55

I guess this problem may occur principally for people using dual boot. Is my hypothesis right?

Harey · 2009-11-30 09:39:52

manouchk wrote:

I guess this problem may occur principally for people using dual boot. Is my hypothesis right?

Yes. You have to synchronize the behaviour of all OSes that will boot on this machine. Otherwise they will eventually be setting the hardware clock assuming that the are 'alone'. I suggest you set your hwclock to UTC. For windows set RealTimeIsUniversal in Windows registry as cleanrock suggested, for arch set HARDWARECLOCK="UTC" in /etc/rc.conf.

Harvey

Arch Linux

#1 2009-10-04 18:16:29

System time / hwclock mismatch, must manual fsck each boot

#2 2009-10-04 18:59:37

Re: System time / hwclock mismatch, must manual fsck each boot

#3 2009-10-04 20:00:23

Re: System time / hwclock mismatch, must manual fsck each boot

#4 2009-10-04 20:05:52

Re: System time / hwclock mismatch, must manual fsck each boot

#5 2009-10-05 13:20:12

Re: System time / hwclock mismatch, must manual fsck each boot

#6 2009-10-05 13:27:54

Re: System time / hwclock mismatch, must manual fsck each boot

#7 2009-10-05 14:11:43

Re: System time / hwclock mismatch, must manual fsck each boot

#8 2009-10-09 10:06:25

Re: System time / hwclock mismatch, must manual fsck each boot

#9 2009-10-09 12:03:44

Re: System time / hwclock mismatch, must manual fsck each boot

#10 2009-10-09 12:27:17

Re: System time / hwclock mismatch, must manual fsck each boot

#11 2009-10-15 18:13:26

Re: System time / hwclock mismatch, must manual fsck each boot

#12 2009-10-15 20:19:23

Re: System time / hwclock mismatch, must manual fsck each boot

#13 2009-10-31 09:18:49

Re: System time / hwclock mismatch, must manual fsck each boot

#14 2009-11-01 13:28:21

Re: System time / hwclock mismatch, must manual fsck each boot

#15 2009-11-01 18:30:08

Re: System time / hwclock mismatch, must manual fsck each boot

#16 2009-11-02 13:28:20

Re: System time / hwclock mismatch, must manual fsck each boot

#17 2009-11-29 13:28:55

Re: System time / hwclock mismatch, must manual fsck each boot

#18 2009-11-30 09:39:52

Re: System time / hwclock mismatch, must manual fsck each boot

Board footer