Bug 17887 - time 20 years back during an installation
Summary: time 20 years back during an installation
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.3
Hardware: alpha
OS: Linux
Target Milestone: ---
Assignee: Matt Wilson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-09-26 21:41 UTC by Michal Jaegermann
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-10-17 18:11:53 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michal Jaegermann 2000-09-26 21:41:11 UTC
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 17:06:22 UTC
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 18:11:50 UTC
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 14:25:38 UTC
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 18:41:28 UTC
Related to bug 12437?

Comment 5 Sam Varshavchik 2000-10-24 21:40:25 UTC
Probably.  The installer should certainly make sure that the system clock is
accurate, before the install starts.

Comment 6 Michal Jaegermann 2000-10-25 01:38:03 UTC
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.