[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Scary bugs



On Fri, Jan 28, 2000 at 05:20:05PM -0800, Ryan Murray wrote:
> On Sat, Jan 29, 2000 at 12:23:02AM +0100, Thierry Laronde wrote:
> > On Fri, Jan 28, 2000 at 04:29:37PM +0100, Richard Braakman wrote:
> > > I vote these "most likely to delay the release".  They are difficult
> > > packages that we can't really do without, and seem to have been
> > > abandoned by their maintainers.  Please help.
> > > 
> > > Richard Braakman
> > > [..]
> > > 
> > > Package: util-linux (debian/main).
> > > Maintainer: Vincent Renardias <vincent@debian.org>
> > >   42556 util-linux: hwclock: Continually messes up my clock
> > > [WAITING] Maintainer was contacted on Dec 12, awaiting reply.
> 
> > The reason of this mess is the script /etc/init.d/hwclock.sh, specially
> > this part :
> > 
> > 
> > stop|restart|reload)
> > 	[ "$GMT" = "-u" ] && GMT="--utc"
> > 	hwclock --systohc $GMT
> > 	^^^^^^^^^^^^^^^^^^^^^^
> 
> I don't think that's the problem.  Setting the hardware clock again to
> the system time isn't the problem.  The problem is, as you mention:
> 
> > When the system is going down for halt or reboot, hwclock is set to the
> > value of the system clock and this *modifies /etc/adjtime*.
> 
> /etc/adjtime.  There is no reason to have hwclock trying to calculate
> drift, as either NTP will be used (which is far more accurate), or the
> system will be rebooting between Windows and Linux frequently.
> 
> A new user will expect their time to follow them between OS', so I think
> instead, the support for /etc/adjtime should be removed (comment out the
> --adjust line in hwclock).  That's what I'm doing and don't have these
> problems.

This has nothing to do with making the time follow them between OS's --
what /etc/adjtime does is keep track of the drift, and adjusting the
hardware clock to counteract it.  So it's supposed to make your clock
more accurate in both linux and windows.

-- Nathaniel


Reply to: