[Bug 584484] New: Installation Settings Summary shows time advanced by TZ offset
http://bugzilla.novell.com/show_bug.cgi?id=584484 http://bugzilla.novell.com/show_bug.cgi?id=584484#c0 Summary: Installation Settings Summary shows time advanced by TZ offset Classification: openSUSE Product: openSUSE 11.3 Version: Factory Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: mrmazda@earthlink.net QAContact: jsrain@novell.com Found By: --- Blocker: --- Time zone: EST/EDT (-0500) Local clock time: 23:30 BIOS clock time: 23:30 Time displayed by installation summary: 04:30 This is my 3rd M2 install. This has happened every time. IIRC, this carries over to various config file and directory time stamps, which show for several hours after completion of installation only date and not time in mc displays, because those files & dirs have "date in future" (5 hours advanced). The first time I encountered this I went back to the initial clock setting screen to verify settings, went into detail, and selected NTP syncronization. The display on that screen showed correctly, and still the summary screen showed 5 hours advanced. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c
yang xiaoyu
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c
Lukas Ocilka
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c1
Jiří Suchomel
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c2
--- Comment #2 from Felix Miata
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c3
Felix Miata
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c4
Jiří Suchomel
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c5
Dr. Werner Fink
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c6
--- Comment #6 from Felix Miata
But I am not sure if the logs you attached match the situation you are describing. According to the logs,
So much has happened since that much is lost from my human memory. I did at least 5 M2/M3 installs on at least 5 different machines, possibly as many as 8. I thought I had no machines with BIOS clock set to UTC, but I just booted into BIOS on host big31 (from which I submitted the logs in comment 2. Booting then into 11.1 showed correct local time in top. Rebooting into 11.3 showed time advanced by TZ offset. I changed in YaST to select BIOS clock is UTC, and rebooted into 11.3 to find local time displayed correctly in top.
... so, at which time did it get actually wrong?
I cannot remember, and am not sure if I ever could actually tell. Certainly by the time YaST was actually ready to download and install rpms the time was already incorrectly displayed.
Additionally, in your report you write about summary: does it mean time is shown wrong in summary page,
For every install of M2 and M3 the time in summary was advanced by UTC offset (UTC was only time displayed). Only in the big31 install I erroneously left the UTC box unchecked as was necessary in every other install.
and it is correct after installation? Or does it reain wrong?
I put big31 away and booted host gx110 into BIOS to find it remained set to local time prior to DST switchover last week. I added an hour and booted 11.3 to find correct local time displayed in top. I looked in the M2 install logs for gx110 and see the newest time stamp is about 10:52 and the oldest about 01:16, with the config_diff... at 05:05. In /boot/grub I see device.map written at 10:51 , device.map.old written at 05:04, and stage2 written also at 10:51. /boot/initrd is also written 10:51, while /etc/fstab is 05:00 and /etc/hosts is 01:38. Most March 3 files in /etc are stamped 01:14 to 01:40, but also termcap, grub.conf-old, ksh.kshrc & nsswitch.conf are stamped in hour 05, and grub.conf, ntp.conf, resolv.conf, yp.conf are stamped in hour 10. March 3 files in /etc/sysconfig are of 3 approximately equal groups of hour 01, hour 05 and hour 10, the newest of which are ntp and storage, the oldest of which are displaymanager and sound. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c7
Felix Miata
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c8
Dr. Werner Fink
... This is the reason why the initrd has the possiblity to tell the kernel that CMOS is running in UTC. For this the variable HWCLOCK in /etc/sysconfig/clock should be set to --localtime, then the script mkinitrd has to be executed. This refresh the initrd, that is that /etc/sysconfig/clock, /etc/localtime, and /usr/share/zoneinfo/UTC are copied into initrd.
``... that CMOS is running in localtime ... '' was intended. Beside this for comparision the CMOS time with the system time the tool adjtimex(8) can be used, for a CMOS running in UTC this is
sudo adjtimex -u --compare=2 --- current --- -- suggested -- cmos time system-cmos error_ppm tick freq tick freq 1269334242 0.001811 1269334252 0.001548 -26.3 10000 417797
for a CMOS running in localtime simply skip `-u' to compare CMOS in localtime. Also I'd like to know if your initrd is set up for CMOS running in localtime, please report the output of lsinitrd /boot/initrd | grep -E 'clock|warpclock|UTC|localtime' -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c9
Felix Miata
Also I'd like to know if your initrd is set up for CMOS running in localtime, please report the output of
lsinitrd /boot/initrd | grep -E 'clock|warpclock|UTC|localtime'
[host gx110] bin/warpclock usr/share/zoneinfo/UTC boot/05-clock.sh etc/sysconfig/clock etc/localtime -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c10
--- Comment #10 from Felix Miata
The assumption that a windows partition introduce running CMOS in local time could be wrong ... at least Windows7[tm] can handle CMOS running in UTC.
Note that few of my systems have "Windows" partitions. Those of type 0x07 or 0x17 are OS/2 HPFS partitions (or unformatted reservations for HPFS). Those of type 0x01, 0x11, 0x04, 0x14, 0x06, 0x16, 0x0e, 0x1e are mostly only used by DOS and/or OS/2 and not allowed to be contaminated by Windows longnames. Only my hosts gx150 & gx260 have Windows installed, and have Windows installed to 0x0b or 0x0c. I try to avoid attaching logs from the Factory installs on them unless there are interoperability issues between Linux and Windows that need addressing. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c11
Jiří Suchomel
(In reply to comment #5)
The assumption that a windows partition introduce running CMOS in local time could be wrong ... at least Windows7[tm] can handle CMOS running in UTC.
YaST is using this as a guess, so it is able to at least propose some probable situation. However, Werner, I'm lost in your comments. Everything that happens there regarding the time changes described in comment 4 is during first stage of installation, withing several minutes. I do not understand if YaST is doing anything wrong there, or if we're in some unlucky situation which could not be automatically adjusted... -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c12
--- Comment #12 from Dr. Werner Fink
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c
Dr. Werner Fink
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c13
Jiří Suchomel
Do you have meant comment #5 ... nevertheless my guess was that NTP destroys the setup as it does not know about localtime im CMOS.
Read comment #5 and the correction in comment #8 as simple cook book to get it right.
The problem is, I do not see comment #5 (+8) as "simple cook book". I believe we had a working solution in previous versions and now it's getting too complicated and I just do not see what current YaST is doing wrong. So, I'll try to summarize once again what YaST is doing in case user says CMOS is in localtime: 1. Set the time zone (/usr/sbin/zic -l <timezone>) 2. /sbin/hwclock --systz --localtime --noadjfile && touch /dev/shm/warpclock 3. This is done before the ntp call, so ntpd should know the time zone. 4. Now, ntpd is called 5. And the (NTP) changed system time is saved back to HW clock by "/sbin/hwclock --systohc --localtime" So, does NTP destroy the setup? It changes the system time, but that one should be correctly written to bios using the hwclock call in 5, and the hwclock has the knowledge about the time format in BIOS... I'm realizing that /etc/sysconfig/clock is not saved before that NTP call, so maybe this is the problem? But do I really have to call mkinitrd when hwclock should know about the time format, because of --localtime argument? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584484
http://bugzilla.novell.com/show_bug.cgi?id=584484#c14
Jiří Suchomel
participants (1)
-
bugzilla_noreply@novell.com