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? . -- From Eric (Mozilla l.1 in Linux, SuSE 8.1) http://www.oh-bugger.net.nz http://homepages.paradise.net.nz/erichard/ NO ATTACHMENT WAS SENT WITH THIS EMAIL IF THERE IS ONE IT IS A UNDETECTED VIRUS, PLEASE LET ME KNOW ....
On Saturday 23 November 2002 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
Yes, by default SuSE runs hwclock --systohc when you shut the system down.
I think this is a problem. sound like a linux virus?
Sounds more like you have the wrong time zone setting. Anders
Sounds more like you have the wrong time zone setting.
No I check that all the time and it never changes
thanks Anders Johansson
Anders
-- From Eric (Mozilla l.1 in Linux, SuSE 8.1) http://www.oh-bugger.net.nz http://homepages.paradise.net.nz/erichard/ NO ATTACHMENT WAS SENT WITH THIS EMAIL IF THERE IS ONE IT IS A UNDETECTED VIRUS, PLEASE LET ME KNOW ....
On Sat, 23 Nov 2002 14:11:59 +1300
Eric Richards
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?
Do you have "boot.clock" enabled in services in the runlevel editor? It need to at least be enabled for [B] (boot). You should see a line when booting: "Setting up Cmos clock". Then make sure your Time is set for --localtime in sysconfig editor, and your timezone is set right, not the "default timezone" but the "timezone" setting. -- use Perl; #powerful programmable prestidigitation
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
On Sunday 01 December 2002 22.32, wolfi wrote:
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.
It could be the --adjust. Do you have something weird in /etc/adjtime? Anders
On Sun, 2002-12-01 at 22:43, Anders Johansson wrote:
On Sunday 01 December 2002 22.32, wolfi wrote:
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.
It could be the --adjust. Do you have something weird in /etc/adjtime?
Anders
Hi Anders, I'm gonna check it out. /etc/adjtime says: -86193.046943 1038777802 0.000000 1038777802 UTC Is this weird ?? Wolfi ============================================= mailto:wolfi_z@gmx.net
On Sunday 01 December 2002 22.48, wolfi wrote:
Hi Anders,
I'm gonna check it out.
/etc/adjtime says:
-86193.046943 1038777802 0.000000 1038777802 UTC
Is this weird ??
Yes, I think so. IINM, I think it means your system gets its hardware clock adjusted by 86193 seconds for each day that's passed since the last system clock setting. I think there's something wrong with the way you set your time zone when you installed. Anders
On Sun, 2002-12-01 at 22:53, Anders Johansson wrote: (...)
Yes, I think so. IINM, I think it means your system gets its hardware clock adjusted by 86193 seconds for each day that's passed since the last system clock setting. I think there's something wrong with the way you set your time zone when you installed.
Anders
Hi Anders, What do you think, should I just kill (rm) this file or copy it from my other box (which sits in the same time zone but works w/o problems) ???!?! Cheers .... Wolfi ============================================= mailto:wolfi_z@gmx.net
Hi all, I now managed to shut down the box and reboot it without getting the time settings messed up. What I did: After Anders suggested, that my /etc/adjtime file might be faulty, I renamed it to /etc/adjtime.old to disable it. Then I went into YaST2, timezone settings, changed something, changed it back, just to make sure YaST2 will write the data which I basically only wanted to make sure it will be 'kept'. The new /etc/adjtime looks as follows: 0.000000 0 0.000000 0 UTC Thanks to Anders & Cheers .... Wolfi ============================================= mailto:wolfi_z@gmx.net
The 02.12.01 at 22:48, wolfi wrote:
/etc/adjtime says:
-86193.046943 1038777802 0.000000 1038777802 UTC
Is this weird ??
Just delete it, which forces the boot script to recreate it and initialise the time adjust. In the script you posted you can see how it is recreated. -- Cheers, Carlos Robinson
The 02.12.01 at 22:32, wolfi wrote:
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.
It sets system clock from CMOS (BIOS) time. Look the manual page: --hctosys Set the System Time from the Hardware Clock. Also set the kernel's timezone value to the local timezone as indicated by the TZ environment variable and/or /usr/share/zoneinfo, as tzset(3) would interpret them. The obsolete tz_dsttime field of the kernel's timezone value is set to DST_NONE. (For details on what this field used to mean, see settimeofday(2).) This is a good option to use in one of the system startup scripts.
The BIOS time gets adjusted to system time, and then it's wrong. Exactly as described in Eric's first email.
ANY IDEAS ???!?!?
Timezones, adjtime, set up bios time (UTC) from the bios itself... -- Cheers, Carlos Robinson
The 02.12.01 at 22:32, wolfi wrote:
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 ???!?!?
One more I discovered today - windows changed my time to winter time, and now I have problems. If you delete /etc/adjust, after running ntpdate it will have "LOCAL" on it, meaning local time. I think I had UTC there previously, so I deleted the file again. The boot script will recreate it correctly, I hope. -- Cheers, Carlos Robinson
On Mon, 2002-12-09 at 22:22, Carlos E. R. wrote:
One more I discovered today - windows changed my time to winter time, and now I have problems. (...)
Hi Carlos, Basically, this is a point, but as far as I have seen, windoze only changes time by one hour. And then your clock is wrong by one hour, and that's it. If you get total crap in your system time, there must be something more weired going on (I assume). Windoze can't write to your /etc/adjust file. Cheers .... Wolfi ============================================= mailto:wolfi_z@gmx.net Linux ... the better OS!
If you dual-boot into Windows you must set your Linux time to "localtime" not UTC to keep accurate machine time between Windows and Linux boots. I had changed to UTC under SuSE 8.1 and time was always wrong after having booted to Windows (98, 98SE, Win2K). Deleting the /etc/adjtime worked only for a login session. Once I reset SuSE 8.1 to "localtime" its been rock solid under both OSes. Stan wolfi wrote:
On Mon, 2002-12-09 at 22:22, Carlos E. R. wrote:
One more I discovered today - windows changed my time to winter time, and now I have problems. (...)
Hi Carlos,
Basically, this is a point, but as far as I have seen, windoze only changes time by one hour. And then your clock is wrong by one hour, and that's it. If you get total crap in your system time, there must be something more weired going on (I assume). Windoze can't write to your /etc/adjust file.
Cheers .... Wolfi ============================================= mailto:wolfi_z@gmx.net
Linux ... the better OS!
The 02.12.10 at 09:00, SRGlasoe wrote:
If you dual-boot into Windows you must set your Linux time to "localtime" not UTC to keep accurate machine time between Windows and Linux boots. I had changed to UTC under SuSE 8.1 and time was always wrong after having booted to Windows (98, 98SE, Win2K). Deleting the /etc/adjtime worked only for a login session. Once I reset SuSE 8.1 to "localtime" its been rock solid under both OSes.
I know. But I use windows perhaps 5% of the time, so I prefer it the other way round :-) In W-Me I have set the "don't adjust for winter/summer time", and it leaves the clock alone - almost - but this time I was restoring windows from backup, and it decided to change the hour before I had time to say "no" :-( There is another issue. Ntpdate can be used to correct the drift of the bios clock, and that is what the /etc/adjtime is for. This adjustment is shattered if we run windows, because windows is continually updating the system time copying it to the hardware or cmos or bios time. -- Cheers, Carlos Robinson
The 02.12.10 at 07:21, wolfi wrote:
On Mon, 2002-12-09 at 22:22, Carlos E. R. wrote:
One more I discovered today - windows changed my time to winter time, and now I have problems. (...)
Hi Carlos,
Basically, this is a point, but as far as I have seen, windoze only changes time by one hour. And then your clock is wrong by one hour, and that's it. If you get total crap in your system time, there must be something more weired going on (I assume). Windoze can't write to your /etc/adjust file.
That's correct, but when I modified the hour in linux, the next time I booted up it was also off by one hour. I had to adjust the time, run ntpdate, hwclock from sys to cmos to make sure, delete /etc/adjtime, and the next time I rebooted I checked the time from inside the bios before going on - this time, it was correct. The problem with deleting /etc/adjust is that ntpdate defaults to localtime (bug? config?), so it is better to delete it again, or edit it like: 0.000000 0 0.000000 0 UTC Also, the suse bootup scripts create it correctly as above. -- Cheers, Carlos Robinson
participants (6)
-
Anders Johansson -
Carlos E. R. -
Eric Richards -
SRGlasoe -
wolfi -
zentara