http://bugzilla.novell.com/show_bug.cgi?id=584484 http://bugzilla.novell.com/show_bug.cgi?id=584484#c Lukas Ocilka changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|locilka@novell.com |jsuchome@novell.com -- 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#c2 --- Comment #2 from Felix Miata 2010-03-09 12:01:12 UTC --- Oops, forgot. https://bugzilla.novell.com/attachment.cgi?id=345439 -- 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#c4 Jiří­ Suchomel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO CC| |werner@novell.com InfoProvider| |mrmazda@earthlink.net --- Comment #4 from Jiří­ Suchomel 2010-03-22 15:12:35 UTC --- Sorry for the delay. But I am not sure if the logs you attached match the situation you are describing. According to the logs, - system starts with 05:19:14, which should be your BIOS time, - than it moves to 00:19:21 when it sets the default time zone US/Eastern and UTC clock, - and when it finds windows partition, it assumes you are using local time and switches back to 05:20:11. - then there's NTP sync, which moves the time again to 00:20:15, - and another call of "/sbin/hwclock --systz --localtime --noadjfile && touch /dev/shm/warpclock" gets it once again to 05:20:21 .. so, at which time did it get actually wrong? Additionally, in your report you write about summary: does it mean time is shown wrong in summary page, and it is correct after installation? Or does it reain wrong? Werner, don't we see a wrong result of the fix introduced in bug 540638? -- 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#c6 --- Comment #6 from Felix Miata 2010-03-22 19:18:10 UTC --- Created an attachment (id=349876) --> (http://bugzilla.novell.com/attachment.cgi?id=349876) y2logs from Mar 3 M2 install on host gx110 (In reply to comment #4)

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#c8 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |mrmazda@earthlink.net --- Comment #8 from Dr. Werner Fink 2010-03-23 08:57:13 UTC --- (In reply to comment #5) One correction

... 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#c10 --- Comment #10 from Felix Miata 2010-03-23 13:43:58 UTC --- (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.

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#c12 --- Comment #12 from Dr. Werner Fink 2010-03-26 17:21:27 UTC --- 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. Sidemark: IMHO we should not support CMOS running in localtime anymore as this is at least a bug, it always causes trouble. Is the user aware the day light saving switches, do we have the correct TZ offset, are the time stamps in the inodes of the mounted file systems correct ... all problems would not apear if any CMOS around the world would run in UTC. -- 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#c13 Jiří­ Suchomel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |werner@novell.com --- Comment #13 from Jiří­ Suchomel 2010-03-29 07:34:48 UTC --- (In reply to comment #12)

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.