https://bugzilla.novell.com/show_bug.cgi?id=699400
https://bugzilla.novell.com/show_bug.cgi?id=699400#c38
Archie Cobbs changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |archie@dellroad.org
--- Comment #38 from Archie Cobbs 2011-12-22 21:59:52 UTC ---
We are seeing this problem also. To summarize:
1. Server arrives with crazy HW clock set in the future
2. We image it (using kiwi)
3. System start running, sets system clock from HW clock
4. System clock is crazy wrong, until...
5. ntpd synchronizes and corrects the system clock
6. Certain daemons see the clock jump backwards, start behaving incorrectly
7. System continues running for days, weeks, months
8. System reboots
9. Goto step #3
This problem repeats indefinitely and never corrects itself.
I don't see how this is not a bug.
The bug, as pointed out earlier, is in /etc/init.d/boot.clock's assumption that
11-minute mode implies accurate hardware clock... this is wrong!
So, my dumb question: why not just change the logic of "/etc/init.d/boot.clock
stop" so that the hardware clock is updated even if the kernel is in 11-minute
mode?
It seems like that would solve this problem and also has zero downside:
--- boot.clock.orig 2011-12-22 15:56:01.178611899 -0600
+++ boot.clock 2011-12-22 15:56:48.018584892 -0600
@@ -154,11 +154,6 @@
rc_status -v
;;
stop)
- if test "$ELEVENMIN_MODE" = yes ; then
- echo "The System Time is in sync with Hardware Clock
${stat}${done}good${norm}"
- rc_status
- rc_exit
- fi
if test "$USE_HWCLOCK" = yes -a "$SYSTOHC" = yes ; then
echo -n "Set Hardware Clock to the current System Time"
#
What am I missing?
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.