Bug 435315

Summary: /etc/rc.d/rc.sysinit can't set the system clock
Product: Red Hat Enterprise Linux 5 Reporter: Martin Poole <mpoole>
Component: initscriptsAssignee: initscripts Maintenance Team <initscripts-maint-list>
Status: CLOSED WONTFIX QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.1CC: kzak, notting, tao
Target Milestone: rc   
Target Release: ---   
Hardware: s390x   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-03-11 17:51:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 435312    
Bug Blocks:    

Description Martin Poole 2008-02-28 17:32:50 UTC
+++ This bug was initially created as a clone of Bug #435312 +++

Escalated to Bugzilla from IssueTracker

-- Additional comment from tao 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
  fi
  rc_status -v -r
 else
  ...

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 08:53:50 UTC
Note, for discussion about this issue see bug #435312.

Comment 2 Bill Nottingham 2009-03-11 17:51:54 UTC
Dependent bug closed, closing this one.