![](https://seccdn.libravatar.org/avatar/2828692fa4df3f8fca81b4f1de6f6e95.jpg?s=120&d=mm&r=g)
On Sat, 2002-11-23 at 02:11, Eric Richards wrote:
Sorry, it is bit of a nut case,
You set up the correct time in the BIOS, load to the log-on and the time is wrong, shut down to the BIOS again and the BIOS time is the same as what was seen at the log-on
I think this is a problem. sound like a linux virus?
Hi Eric, Did you find a solution for this? I have got exactly the same problem on one of my boxen. In /etc/init.d/boot.clock it says -> see below. This one seems to be important: /sbin/hwclock --hctosys $HWCLOCK which means, that on boot system time is adjusted to BIOS time. But in fact, the opposite happens. The BIOS time gets adjusted to system time, and then it's wrong. Exactly as described in Eric's first email. ANY IDEAS ???!?!? Cheers ... Wolfi ============================================= mailto:wolfi_z@gmx.net #! /bin/sh # # Copyright (c) 2001-2002 SuSE Linux AG, Nuernberg, Germany. # All rights reserved. # # /etc/init.d/boot.clock # ### BEGIN INIT INFO # Provides: boot.clock # Required-Start: boot.localfs # X-UnitedLinux-Should-Start: boot.crypto boot.swap # Required-Stop: # Default-Start: B # Default-Stop: # Description: set cmos clock ### END INIT INFO . /etc/rc.status . /etc/sysconfig/clock rc_reset case "$1" in start) # set and adjust the CMOS clock if [ "$HOSTTYPE" = "s390" -o "$HOSTTYPE" = "s390x" ] ; then echo -n Setting up the system clock # On s390 the hwclock is set outside Linux currently. The kernel # always assumes it to be set to UTC. So if it is set to local # time, we have to compensate for that. We might achieve this # using this special settimeofday(2) linux feature: # Under Linux there is some peculiar `warp clock' semantics # associated to the settimeofday system call if on the very # first call (after booting) that has a non-NULL tz argu- # ment, the tv argument is NULL and the tz_minuteswest field # is nonzero. In such a case it is assumed that the CMOS # clock is on local time, and that it has to be incremented # by this amount to get UTC system time. No doubt it is a # bad idea to use this feature. (settimeofday(2) man page) # But unless someone complains we simply will use date(1) to shift # the system time by the difference between UTC and local time, if # the system clock is set to local time. This will introduce a # minimal shift due to the delay between gettimeofday and # settimeofday, and it only works as long as $0 is executed # exactly once, at boot. if test "$HWCLOCK" != "-u"; then date $(date -u +'%m%d%H%M%Y') rc_status fi rc_status -v -r else echo -n Setting up the CMOS clock test -f /etc/adjtime || echo "0.0 0 0.0" > /etc/adjtime /sbin/hwclock --adjust $HWCLOCK rc_status /sbin/hwclock --hctosys $HWCLOCK rc_status rc_status -v -r fi ;; stop) rc_failed 3 rc_status -v ;; status) rc_failed 4 rc_status -v ;; *) echo "Usage: $0 {start|stop|status}" exit 1 ;; esac rc_exit