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 <[EMAIL PROTECTED]> > > > 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
