Hide Forgot
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@harddata.com
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.