******************** original post **************************
SUN Ultra2 Enterprise server
Solaris 2.6
Veritas Volume Manager 2.5.2
Recommended Patch Cluster (recent) + selected ssa related patches c0t0d0
(/, /usr, /var, /opt, /export/home) excluded from vxvm control
SSA 110
Firmware upgraded to revision 3.12
c1t[0-5]d0 are the only disks in ssa (six of them) and under vxvm control
The server in question is part of year 2000 certification lab. Each
project/app coming to the lab gets the "baseline" OS ufsrestored from tape.
The "baseline" includes full (all options) Solaris OS + VxVm + SYBASE
11.0.3.2. After ufsrestore vxvm is initalised and disks are brought under
its control, volumes get configured, SYBASE devices are created, and
database dumps are loaded to recreate databases.
Next step involves running an app throughout numerous test cases with the
system clock set to different dates. One of the important dates in Y2K
testing is a date offset by 28 years from current date. It gives same day
of the month as well as the same day of the week.
To change the system date we do: init 0, boot -s, date ..., init 6
1998, 2004 no problem, normal expected behaviour.
When system clock set to year 2026 and booting following happens: 1.
~/rcS.d/S25vxvm-sysboot attempts to start vxconfigd
2. vxconfigd returns segmentation violation
3. vxconfigd dumps core (file core reveals it is 'vxconfigd' core as
opposite to kernel core)
I enabled vxconfigd logging with debug level=9 (highest).
Booting with OK date I get some 200+k log file. Booting in 2026 log file
does not get generated (tried all possible logging options). To generate
any logs I included 'exec 1>mylog 2>&1' in S25* script, this fails due to
the fact that '/' is 'ro' at the time? So I moved S25* to S71* since my
system disk is not under vxvm control and was able to write a log file out.
Analysing logs from 'OK' boot and '2026' boot (after all that effort !!!)
reveals that first 25 or so lines are identical and first diffrence is the
line saying that vxconfigd just crapped out !!!
My gut feeling is that vxconfigd reads system date and epoch number or
variation of it gets to large for internal variable to handle and kaaabum
!!! But:
1. It is just my gut feeling and means nothing
2. I do not know how to read core (tools & interpretation) to prove it.
I just wonder if anybody experienced same or similar problem and know the
solution?
******************** end original post **************************
*************** from SUN-MANAGERS mailing list ******************
Klorese, Roger B.A. rogerk@veritas.com
There was a problem in the license management code that we call the "Year
2008" problem. We've already checked in a fix, though I'm not sure in
which release or patch it turns up first.
*************** end from SUN-MANAGERS mailing list **************
CONCLUSION:
Veritas confirmed a bug. Fix is available in new version of the software.
It is version 2.5.3 and includes: VRTSvmdev, VRTSvmman, VRTSvxvm. It does
not include VRTSvxva. It is not GA yet however I have gotten it throughout
Veritas support channels. It installs as an upgrade (pkgadd -d . VRTSvxvm).
Did it, tested it, it works.
Thanks to all who replied.
\gs
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:45 CDT