Still unsolved bug 534816?

There's an old bug from 10.3 here that might be related:

https://bugzilla.novell.com/show_bug.cgi?id=327537

Perhaps their cause is the same?  Also Inge, could you test this with Milestone 8?

I can confirm this bug on Milestone 8 x86_64.  After each reboot the clock is off-set by my differential relative to UTC.  The effect is cumulative with each reboot.

On the openSUSE forums they are reporting that running mkinitrd will solve the problem.  I can confirm this as working on my install of Milestone 8.


http://forums.opensuse.org/pre-release-beta/422857-ping-akoellh-time-bug-m8.html

Changed bug to Milestone 8 (thanks for the confirmation Refilwe) and architecture to "PC" since it appears to be present in the x86_64 build.

Anyone with this bug, please attach:

/etc/sysconfig/clock

/etc/adjtime

/var/log/boot.msg

My clock was set two hours ahead in Milestone 8.

Created attachment 321113 [details]
my boot.msg

boot.msg

Comment on attachment 321113 [details]
my boot.msg

This is my boot.msg, I don't know how to add a seccond attachment.

Created attachment 321114 [details]
The clock file. 

This is my clock file. Sorry for the seccond posting, but bugzilla is not very easy to handle. On my system there is no /etc/adjtime

*** Bug 544436 has been marked as a duplicate of this bug. ***

This is really annoying and it should be fixed as soon as is possible. And i´m just reading forum and people really complain, that time makes problems with BIOS also.

Werner worked on this

The initial description is missing a point:

> 1.install
> 2.untick "Hardware clock set to UTC"

  2a. run mkinitrd to inform the initrd system
      that now the CMOS time is in local time

> 3.Log in after installation
> 4.Reboot

... maybe this should be done the YaST mask used for
unsticking the UTC time.

OK, I've submitted an aaa_base which includes now two scripts
.. first of all a `refresh_initrd' which currently checks only
if /etc/sysconfig/clock is newer than /boot/initrd and run
mkinitrd in this case (there can be added more conditions).

As the YaST timezone module currently igniores the tags within
/etc/sysconfig/clock (like the added Command tag) I've added
a /sbin/conf.d/SuSEconfig.clock to run refresh_initrd in any
case.

Thorsten is not really a fan of this solution and prefers a command comment in the sysconfig (this could be restart_initrd) - this would leave the installation. But I have no idea what's the order of writing out sysconfig/clock and installing kernel.

I've added also the Command tag to /etc/sysconfig/clock found in
aaa_base (which only works on a fresh install) ... you may remove
the SuSEconfig.clock including the empty conf.d/ in the tar
ball of aaa_base if the YaST timezone module does it correct.

(IMHO all YaST modules should honour the tags within sysconfig files
 as done by the YaST sysconfig editor module)

I'm afraid the installation needs to call mkinitrd before reboot as it saves the HWCLOCK value after all packages are installed, so mkinitrd called during package installation will see the defaull (UTC) -> bang

(In reply to comment #15)

> But I have no idea what's the order of writing out
> sysconfig/clock and installing kernel.


sysconfig/clock is written by Timezone::Save, which is invoked in save_config_finish.ycp.

(In reply to comment #17)
> I'm afraid the installation needs to call mkinitrd before reboot as it saves
> the HWCLOCK value after all packages are installed, so mkinitrd called during
> package installation will see the defaull (UTC) -> bang

So is this an action that is required from YaST? Than it should be done by installation at the end of first stage...

The order is:

      * write out /etc/sysconfig/clock
      * set the CMOS time to local time
      * run mkinitrd to get /etc/sysconfig/clock into initrd
      * reboot into new kernel with its new initrd

then the new initrd runs warpclock to inform the new kernel
that CMOS is running in local time. Beside this initrd touch
a lock file to skip /etc/init.d/boot.clock to touch the
CMOS clock again.

Well, I admit I do not understand it at all.

1. What should YaST do differently from previous distributions where it worked and why?

2. What are those Command tags you are writing about and how (if) they should be used?

3. Why should YaST explicitely "set the CMOS time to local time"? When user unchecks that "UTC checkbox", it is expected that his CMOS time is already local, there's nothing to set...

If CMOS clock is running in localtime than you're right. In this case
the CMOS clock should be not touched.  Beside this normally the Linux
kernel assumes that CMOS is running in UTC.  That is that during boot
the kernel set to the system time to UTC (and the glibc is using
/etc/localtime to caluate the correct offset for displaying the system
time in the local time frame).  Now with the help of the binary warpclock
in the initrd the kernel will be informed that the CMOS is *not* running
in UTC but in local time together with the offset to UTC.  Then the
kernel its self correct the system time to the UTC time.  This is done
*before* the root file system is mounted (to avoid a root file system
mounted in the future for systems right of the meridian of the
international dateline).

So this is the same case as we previously called 

"user selected local time, even if he uses UTC" -> user error & invalid bug

If user leaves UTC checkbox in the correct state (saying UTC if he has UTC in CMOS, unchecking UTC only when CMOS time is already local), that everything works fine, right?

I am sorry but I still don't see where and when should YaST do some new action - before reboot? But after first reboot, it works correctly, only after next reboots time goes wrong.

What about that Command tag? What is there and how should it be used?

The initrd should be created *after* /etc/sysconfig/clock has been changed
otherwise initrd does not know that the CMOS is in local time and can not
inform the kernel on next (re)boot. Therefore this should to be done *before*
the installed kernel is booted form the root partition.  And this is *not* an
users error, this has to be done by YaST at installation before the installed
system is booted.

The Command tag in sysconfig files is currently ignored by the YaST timezone
module. AFAIK only the YaST sysconfig editor uses them.

Here we've the tags of sysconfig files:

 http://en.opensuse.org/SUSE_Package_Conventions/Sysconfig#5.3._Metadata_Tags

(In reply to comment #23)

> The Command tag in sysconfig files is currently ignored by the YaST timezone
> module. AFAIK only the YaST sysconfig editor uses them.

Yes, but I'm the maintainer of YaST timezone module. So I'm asking for this, to see if using this tag wouldn't be easier solution than calling mkinitrd at some time during installation.

How does your new /etc/sysconfig/clock look like?

The part for HWCLOCK looks like this

 ## Path:                System/Environment/Clock
 ## Description:         Information about your timezone and time
 ## Type:                string(-u,--utc,--localtime)
 ## ServiceRestart:      boot.clock
 ## Command:             test -x /sbin/refresh_initrd || /sbin/refresh_initrd
 #
 # Set to "-u" if your system clock is set to UTC, and to "--localtime"
 # if your clock runs that way.
 #
 HWCLOCK=""

and the script /sbin/refresh_initrd is

 #!/bin/bash
 #
 # Refresh initrd depending on conditions.
 # Currently only the change of /etc/sysconfig/clock is
 # honoured but we may add more of conditions.
 #
 # Author: Werner Fink <werner@suse.de>
 #
 refresh=no
 test $ROOT/etc/sysconfig/clock -nt $ROOT/boot/initrd && refresh=yes
 test "$refresh" = yes || exit 0

 line=off
 test -e /proc/splash && read line < /proc/splash
 test -r $ROOT/etc/sysconfig/bootsplash && . $ROOT/etc/sysconfig/bootsplash
 test "$SPLASH" = no && line=off
 if test "${line##*: }" = off ; then
     exec $ROOT/sbin/mkinitrd $ROOT
 fi
 size=${line##*, }
 size=${size%)*}
 exec $ROOT/sbin/mkinitrd -s $size $ROOT

or we use the same Command tag as in /etc/sysconfig/kernel which whould be
simply /sbin/mkinitrd.

So, am I on the safe side if I call this Command script ("test -x /sbin/refresh_initrd || /sbin/refresh_initrd") every time I write  /etc/sysconfig/clock? Regardless it is installation or not?

As long as the command is done in the chroot of the final root partition
and therein /proc and /sys is mounted (to be able to access /proc/splash
and to make mkinitrd work as it alos remains on /proc and /sys) ... yes.

Well, if I'd put it to the same place Timezone saves the sysconfig file (Timezone::Save) that timezone module would not know anything about current root.

Lukas, when Timezone::Save is executed from save_config_finish.ycp, is it already in new chroot?

According to inst_finish.ycp, "save_config" is called after "switch_scr" so -> yes, it is already in the new chroot.

OK ... then one question more: is this chroot with /proc and /sys mounted?
That is that mkinitrd can do its job.

mkinitrd does its job when bootloader calls it later in the same script /proc and /sys should `mounted` already when installing packages (before installing packages).

... so, why mkinitrd "does not do the job" when it is called anyway?

Hmmm ... if /etc/sysconfig/clock and /etc/localtime are changed before
mkinitrd will be executed then the initrd should be uptodate.
/lib/mkinitrd/bin/warpclock depends on /etc/sysconfig/clock and
/etc/localtime which are copied by /lib/mkinitrd/scripts/setup-clock.sh
into the initrd.

Hopefully the mkinitrd_setup is executed by the rpm spec before mkinitrd
is called by any other ... otherwise the setup und boot links in
/lib/mkinitrd/setup/ and /lib/mkinitrd/boot/ are missed.

Timezone::Save does only save  /etc/sysconfig/clock

/etc/localtime of the target system is not modified, this is done by Timezone::Set, which is called during the timezone setup. Timezone::Set does:

/usr/sbin/zic -l <timezone>
/sbin/hwclock --hctosys <hwclock> (where hwclock is the HWCLOCK value from sysconfig)


So... should we call Timezone::Set also after the chroot? Just before Timezone::Save?

Yes please otherwise warpclock nor hwclock now about the offset to UTC.
That is that warpclock nor hwclock can use the hack

   zone.tz_minuteswest = -(typeof(zone.tz_minuteswest))(gmtoff/60L);
   settimeofday((struct timeval *)0, &zone);

as descibed in the manual page settimeofday(2) and in linux/kernel/time.c.

Created attachment 321459 [details]
patch for /usr/share/YaST2/clients/save_config_finish.ycp

So... this would be proposed patch.

Cool ... it would be perfect if this works ... if this happens before
the mkinitrd will run then all should be done, the information about
the CMOS clock as well as the information about the offset to UTC.

OK, I will include the patch above in yast2-installation-2.18.31.

Let's see if it works in next snapshot.

*** Bug 545990 has been marked as a duplicate of this bug. ***

let's mark it as fixed - for now

Reporters: please make sure it works with RC1.

Works with RC1 here. Thank you!

It's fixed with RC1.Thanks!