Bug 754329

Summary:	Make clock handling more robust
Product:	[openSUSE] openSUSE 12.1	Reporter:	Archie Cobbs <archie.cobbs>
Component:	Basesystem	Assignee:	E-mail List <bnc-team-screening>
Status:	VERIFIED NORESPONSE	QA Contact:	E-mail List <qa-bugs>
Severity:	Enhancement
Priority:	P5 - None	CC:	chacea, lmuelle, varkoly, werner
Version:	Final
Target Milestone:	---
Hardware:	PC
OS:	openSUSE 12.1
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Archie Cobbs 2012-03-27 16:04:13 UTC

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20100101 Firefox/10.0.2

The basic problem is that the system hardware clock never gets set correctly on a newly installed system where the hardware clock's factory setting is completely wrong, even when you are running ntpd. As a result, every time the system reboots, the clock is reset back to the wrong time again.

Please see Bug #699400 for a description of the problem. It is complicated and has some subtleties. However it is 100% reproducible, the cause is completely understood, and it has affected to many people as witnessed by the comments.

Even so, someone marked that bug resolved/invalid.

OK, if everything is working "fine", this consider this a feature request to make everything work "even better".

Even though he believes the bug is invalid, in comment #40 https://bugzilla.novell.com/show_bug.cgi?id=699400#c40 Werner Fink proposes some solution(s).

This issue is being filed to request those solution(s).


Reproducible: Always

Steps to Reproduce:
1. Set hardware clock to a crazy value
2. Boot system, enabling NTP
3. Let NTP set system (not hardware) clock correctly
4. Power cycle system
5. Clock will be set to crazy value again




Bug #699400

Comment 1 Dr. Werner Fink 2012-03-27 16:36:16 UTC

You may use the FATE API to fill in a feature request ... beside this do
have given the latest boot.clock from package aa_base and package ntp
from factory a try?  With this this bug should be fixed as the new boot.clock
-- if enabled -- will check if the hardware clock goes crazy and with
new ntp the hardware clock should be correct at start of ntp (done due bug
#730374).

Comment 2 Archie Cobbs 2012-03-27 17:53:33 UTC

Thanks. I have not tried the new boot.clock and ntp.

If you are confident that they fix the problem I'll take your word for it and you can resolve this bug (I have a hard time understanding what the shell scripting does exactly).

But does it fix this scenario?

1. Hardware clock is crazy
2. NTP is running, sets system clock correctly
3. System is shutdown, but hardware clock is not corrected
4. System restarts, but ntp is not started (e.g., you might be in single user mode)
5. System clock is back to crazy value

I am not authorized to view bug #730374 so I can't tell anything about it.

Comment 3 Dr. Werner Fink 2012-03-28 07:42:08 UTC

(In reply to comment #2)

> Thanks. I have not tried the new boot.clock and ntp.

It would be prefect if you would give the new boot.clock and the ntp package
a try.  The ntp package includes a change in the boto scipt which should
correct the hardware clock before ntpd will be started.  For this the new
variables NTPD_FORCE_SYNC_ON_STARTUP  and  NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP
have been added to /etc/sysconfig/ntp.  The first option does force sync
of the system clock and the second one also for the hardware clock.

The change in boot.clock simply determines the real offset of the hardware
clock to be able to detect an offset between system and hardware clock with
more the 900 seconds.  You may test this on the command line with

 TZ=UTC /bin/date +'%s' && cat /sys/class/rtc/rtc0/since_epoch

The frist command provides the system clock and the second will show the
hardware clock on modern kernels.

I've asked the people from bug #730374 if it is OK to add you to CC list.

Comment 4 Kun Kun Zhang 2012-05-14 07:56:27 UTC

Long time no resposne.So closed.Feel free to reopen it.Thank you:)