Bug 17887

Summary:	time 20 years back during an installation
Product:	[Retired] Red Hat Linux	Reporter:	Michal Jaegermann <michal>
Component:	anaconda	Assignee:	Matt Wilson <msw>
Status:	CLOSED DEFERRED	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3
Target Milestone:	---
Target Release:	---
Hardware:	alpha
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-10-17 18:11:53 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:

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".

  Michal
  michal

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.