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".
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 ...?
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.
thanks for your additional info, Michal ... this 'clock consistency' issue will
probably be deferred to the next release ... thanks for your report!
Related to bug 12437?
Probably. The installer should certainly make sure that the system clock is
accurate, before the install starts.
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.