Bug 8177 - hwclock utility broken on UX
hwclock utility broken on UX
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: util-linux (Show other bugs)
6.1
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Erik Troan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-01-04 18:30 EST by michal
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-08 20:34:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description michal 2000-01-04 18:30:41 EST
The current version of 'hwclock' when supplied with -A flag (or
equivalently --arc) returns on UX, a.k.a. Ruffian, shfited back
by 20 years.  As startup files in 6.1 do that regardless of
settings in /etc/sysconfig/clock, which likely should be classified
as a bug on its own, then 6.1 installation on UX ends up with
a funny time.

To add to an aggravation the maintainer of util-linux insists
that this a correct behaviour.  Technically he is right as a hardware
clock on UX indeed is somewhat unusual but this behaviour violates
a long established practice and a "principle of the least surprise";
users are NOT expected to memorize minutae of a hardware clock
implementation on particular boards.

An alternate implemenation of a function from clock/cmos.c, which restores
sanity, is included in an attached file.  It is not totally full-proof
as it may fail if /proc is not mounted, but then startup scripts
will have other problems to worry about.

Michal Jaegermann
michal@harddata.com
Comment 1 Jeff Johnson 2000-05-15 08:58:59 EDT
Sorry to bother again, but could you reply to this message with the
clock/cmos.c attached, as the file is not attached? A pointer to
a src rpm with your changes to util-linux is probably even a better
idea. Thanks.
Comment 2 Michal Jaegermann 2001-02-06 14:47:33 EST
This old report got, in a sense, obsoleted by further developments.  The
current 'hwclock', from util-linux, is quite good at guessing clock types
on a hardware in question and there is in reality more than two of these. :-(
At least I do not know platforms where this guessing fails so the best
policy is _not_ to set -A, or -S, flag in startup scripts unless explicitely
requested in /etc/sysconfig/clock.  A default in this configuration file
should be "none".  In any case it is totally unacceptable overriding this
choice in /etc/rc.d/rc.sysinit because a boot via milo was detected.  The
later is a root cause of troubles on UX as it boots with milo and its clock
does not conform to ARC specifications.

I do not have this UX anymore but when I had it following the policy outlined
above was what was needed.  The only problems were showing during updates
when Red Hat tools were trying to "outsmart" me (see #17877).  Also for
quite a while Hard Data ships all its Alpha machines with a preloaded
software (i.e. nearly all of these) configured according to this policy
and I still have to hear complaints because of that. :-)  It was not
possible to do that in the past when clock utilities were not smart enough.

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