Bug 435315 - /etc/rc.d/rc.sysinit can't set the system clock
/etc/rc.d/rc.sysinit can't set the system clock
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: initscripts (Show other bugs)
s390x Linux
medium Severity medium
: rc
: ---
Assigned To: initscripts Maintenance Team
Brock Organ
Depends On: 435312
  Show dependency treegraph
Reported: 2008-02-28 12:32 EST by Martin Poole
Modified: 2009-03-11 13:51 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-11 13:51:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Martin Poole 2008-02-28 12:32:50 EST
+++ This bug was initially created as a clone of Bug #435312 +++

Escalated to Bugzilla from IssueTracker

-- Additional comment from tao@redhat.com on 2008-02-28 12:26 EST --
Our customer is running the 64-bit RHEL4 U5 s390x distribution on an IBM System
z9 BC.

There is no hwclock command in zSeries Linux to allow the System clock to be set
correctly when the Hardware Time-of-Day (TOD) Clock is set to Local time. In
/etc/rc.d/rc.sysinit the Red Hat s390x distribution states that the System date
on S390 is always set correctly, by which it means that the zSeries TOD clock
keeps time in UTC.

For those systems where this is not the case, the Novell s390 distribution
provides the following compensation in their /etc/init.d/boot.clock script:

 # 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 -v -r

We would like a similar compensation in the Red Hat boot scripts to allow
correct time in the event that the Hardware TOD clock is set to Local time.

Could we get a hotfix for the rhel4 u5 initscripts-7.93.29.EL-1.s390x.rpm
package as well having the fix added to all future releases of RHEL4 and RHEL5.
This event sent from IssueTracker by mpoole  [SEG - Base OS]
 issue 166134
Comment 1 Karel Zak 2008-03-03 03:53:50 EST
Note, for discussion about this issue see bug #435312.
Comment 2 Bill Nottingham 2009-03-11 13:51:54 EDT
Dependent bug closed, closing this one.

Note You need to log in before you can comment on or make changes to this bug.