OS installed in the future

[Paul Sperry]

I was running the freedisk utility
and got the forrowing error.

ERROR: The install date for Accounting.ACCOUNTNG is in the future!
Do not use freedisk until the system clock indicates it is at least
'200307201625.09'. See the date(1) man page for more information.

# date
Thu Feb 13 12:48:12 MST 2003


I went into swremove to verify the install date
and noticed it wasn't just accounting but my whole OS HPUXBase64 HPUXBaseAux, HWEnable11i etc...All had an install date of july 20 2003

Individual patches that I put on for oracle
had the correct dates.

Any ideas on how I can change the date?
Or should I just wait till July.

Thanks

[James R. Ferguson]

Hi Paul:

Personally, I would *not* use 'freedisk'. As the man pages note, the utility attempts to find and remove filesets that *appear* not to have been removed. With disk so cheap and with the ability to expand filesystems (or even reinstall vg00 with Ignite), I certainly don't want to 'swremove' anything so capriously.

Regards!

...JRF...

[Brian M Rawlings]

Sounds like whoever did your OS load didn't pay much attention to the date/time. I don't know of any convenient way to fix this, other than a reload, or maybe ignite... but an ignite reload from make_tape_recovery doesn't change file timestamps to the reload date/time... don't know if it would make swremove (or other ignite commands) see corrected date or not.

One reason that occurs to me that you should trouble yourself to fix this is that patching (swinstall) functions are somewhat dependant on timestamps to make sure all dependancies are met... you could run into trouble when applying new patches if they think the old ones are "newer" than the new ones, stuff like that.

As Jim says, freedisk was once useful, but do you really need to do this on your system? It provides little value (and potential for problems/mistakes) on modern servers with large boot drives.

Regards, --bmr

[Paul Sperry]

I really wasn't intending to remove anything
with freedisk I was just woundering what it
thought had not been used since installation.

Any ideas on changing the date?

[Bill Hassell]

Don't change the date while the system is running! While HP-UX doesn't care, having timestamps in logfiles and diretories that are in the future may have some unforeseen effects. But the real issues will be with production data files. Do they contain timestamps imbedded in the data? If so, you have a real project ahead to determine a migration scheme. Exporting the database may be a possibility but it may require filtering to make sense to the corrected database. This is not going to be an easy task at all...yet another reason to always activate NTP for every system as soon as it is installed and before any applications and patches are added.

[Brian M Rawlings]

Bill: I think Paul is asking about ideas on how to fix the incorrect SD/UX timestamps, which are causing swlist or swremove to think that his OS was loaded in July of '03.

Unless Ignite load from a make_tape_recovery tape would fix those "install" dates, I don't know any way to do it. Any ideas?

--bmr

[Pete Randall]

Paul,

Just to clarify things in my own mind at least, do you have any idea what the install dates were before you ran freedisk? I'm trying to get some inkling whether freedisk is the cause or the evidence. If it's the cause (which seems unlikely, I admit) and you have an ignite backup, then the case is closed.

On a facetious note, you could stand to take a few months off, couldn't you?

Pete

[Brian M Rawlings]

And, please let us know if this works to get time off, I won't have any trouble causing a similar time warp...

8^)

[Bruce Laughlin]

Hi Paul,

Even after you get the time/date issues corrected, you may find that you still get the error from freedisk. This is a known problem, but unfortunately isn't documented on the ITRC. From the service request, here is a workaround:

The part of the freedisk(1m) script that fails is:

if [ "$TIME_STAMP" -gt `date '+%C%y%m%d%H%M.%S'` ]
then
echo "\nERROR: The install date for $PROD_FILESET is in the future!"
echo " Do not use freedisk until the system clock indicates
it is at least"
echo " '$TIME_STAMP'. See the date(1) man page for more
information."
exit 1
fi

These `date '+%C%y%m%d%H%M.%S'` values are of the form 199801130954.26.

That floating-point comparison operator "-gt" converts the date strings
of the form "199801130954.26" to floating point. However,
199801130954.26 cast to a (signed) float is negative, so the comparison
fails.

A string comparison would solve the problem.

As a workaround, the script can be modified in the following way:
Looking at line 151 of version 10.1 of the script:

Change: if [ "$TIME_STAMP" -gt `date '+%C%y%m%d%H%M.%S'` ]
to: if [[ "$TIME_STAMP" > `date '+%C%y%m%d%H%M.%S'` ]]

Regards,
Bruce Laughlin
HPUX GSE

[Paul Sperry]

Thanks for all the replys. Something strange is going on here. here is the output from

swlist -a install_date

# Initializing...
# Contacting target "moron"...
#
# Target: moron:/
#

#
# Bundle(s):
#

B3901BA 200307210918.41
B6834AA 200212041431.38
B9788AA 200211131455.52
BUNDLE11i 200307201627.44
CDE-English 200307201627.44
FDDI-00 200307201627.44
FibrChanl-00 200307201627.44
GOLDAPPS11i 200212051503.07
GOLDBASE11i 200212051503.07
GigEther-00 200307201627.44
GigEther-01 200307201627.44
HPUX11i-OE 200307201627.44
HPUXBase64 200307201627.44
HPUXBaseAux 200307201627.44
HWEnable11i 200307201627.44
J4189-11001C 200210250920.20
OnlineDiag 200307201627.44
RAID-00 200307201627.45
#
# Product(s) not contained in a Bundle:
#

PHCO_26061 200212051425.22
PHCO_26331 200212060850.51
PHCO_26466 200212060850.51
PHCO_27020 200212051425.22
PHCO_27434 200212060850.52
PHCO_27780 200301090824.01
PHKL_25233 200212051425.18
PHKL_25468 200212060850.51
PHKL_25871 200212060850.51
PHKL_25993 200212060850.51
PHKL_25994 200212060850.51
PHKL_26468 200212060850.51
PHKL_27091 200212060850.51
PHKL_27094 200212060850.51
PHKL_27096 200212060850.51
PHKL_27151 200210291118.46
PHKL_27152 200211071156.33
PHKL_27179 200212051425.18
PHKL_27278 200212060850.51
PHKL_27294 200212060850.51
PHKL_27502 200212060850.51
PHNE_24512 200302061406.24
PHNE_26388 200212051425.18
PHNE_26728 200212051425.20
PHNE_27063 200212051425.22
PHSS_25685 200210281350.01
PHSS_25985 200301100833.11
PHSS_26138 200302061343.33
PHSS_26493 200212051425.25
PHSS_26560 200212060852.04
PHSS_26971 200212060852.12
PHSS_26973 200212060852.12
PHSS_26975 200212060852.12
PHSS_26977 200212060852.12
PHSS_27258 200212051425.25
PHSS_27425 200212060852.12
PHSS_27428 200212051425.26
PHSS_27526 200210291033.49
PHSS_27850 200302061343.33
bash 200307211107.30
bison 200307211107.30
flex 200307211107.30
gettext 200307211107.30
less 200307211107.30
libiconv 200307211107.30
make 200307211107.31
xenmenu 200211041425.04


Just how serious is this? The system is not in production yet it is going to replace an older system very soon. It's main purpose will be an oracle 9i application server.
Sould I take a few months off :) or spend a
weekend re-building it :(

[Pete Randall]

Paul,

I think the safest bet would be to reload from scratch, however, if you like to gamble . . .

Note that the Core/OS was installed with the bogus date (who did the install, anyway?) and that the GOLDAPPS, GOLDBASE, Gig-Ether, and sundry patches were all installed with a presumably correct date, yet they have to have been installed after the core. It would seem that you won't trip over the bogus date during installations - maybe you don't have to worry about it.

Pete

[Brian M Rawlings]

FWIW, I would try an ignite tape, to see whether the OS thinks it got reloaded as of the reload date, or if all the OS/Ignite files just get put back as they are now.

Ignite acts like it's doing an install upon booting the tape, asking all the 'install' questions and letting you create all the root volumes and file systems, but then it just 'untars' archives back into the file systems. I'm not sure where the "install" part stops, and the "tar" restore (with original timestamps) starts.

Unless somebody can definitively state that "this won't help", what's the harm in trying it? You invest a couple of hours to perhaps save a week... nice ROI if it works, small investment if it doesn't.

Anyone? Bueller? Bueller? I'd give it a try, myself.

Regards, --bmr

[Paul Sperry]

I don't have an ignite tape or server but I guess I could set one up. But wouldn't ignite
basically re-intall the os like a cold intall?

I am not much of a gambler but I am a family
man and like to spend the weekends whith them.

Regretfully I must admit that I was the one that install th OS. But I swear I didn't enter a incorrect date during install, then again maybe I did.

Again thanks for all the input.