Bug 17887 - time 20 years back during an installation
time 20 years back during an installation
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Matt Wilson
Depends On:
  Show dependency treegraph
Reported: 2000-09-26 17:41 EDT by Michal Jaegermann
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:
Last Closed: 2000-10-17 14:11:53 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 Michal Jaegermann 2000-09-26 17:41:11 EDT
Installer on Alpha UX sets time 20 years back.  A system time before
and after that installation is correct.  This results in various
"interesting" timestamps on various files and in rpm database.
As a side-effect after a reboot a cron job kicks in and destroys
installation log files in /tmp because they are "20 years old".

Comment 1 Brock Organ 2000-10-17 13:06:22 EDT
hmmm ... I haven't seen this on any machines in our test lab (not verified on a
ux, though) ... does this occur for all installs, or only for special cases ...?
Comment 2 Michal Jaegermann 2000-10-17 14:11:50 EDT
This is a UX problem and I think that I know what that may be.  I had this
conversation already in 6.2 time although not about an installer. :)

I think that some tool assumes that booting from milo implies that ARC
clock is in use.  UX boots _only_ from milo but its clock does not conform
to ARC specifications and forcing it to ARC screws things badly. Current
'hwclock' actually gets it right if not confused with '-A' flag.  Presumably
something in an installer falls in the trap above. 

If you are using in an installation software 'hwclock', or the current
'hwclock' code, then letting it to guess which clock interpretation 
to use seems to be the best policy all over the place.
Comment 3 Brock Organ 2000-10-19 10:25:38 EDT
thanks for your additional info, Michal ... this 'clock consistency' issue will
probably be deferred to the next release ... thanks for your report!
Comment 4 Michael Fulbright 2000-10-24 14:41:28 EDT
Related to bug 12437?
Comment 5 Sam Varshavchik 2000-10-24 17:40:25 EDT
Probably.  The installer should certainly make sure that the system clock is
accurate, before the install starts.
Comment 6 Michal Jaegermann 2000-10-24 21:38:03 EDT
As an explanation to the last comment - the system clock on the machine in
question was and is accurate and this was the problem.  This was an installation
on some partitions of a machine with some other installations already on it
and in a constant active use.

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