WARNING: Time-of-day chip unresponsive; dead batteries?

  While working on a creation of the Web Space Server 10 Virtual Template, I have bumped on a quite annoying OpenSolaris bug which produced a chain of quite unexpected results.


  The mentioned bug occurs on OpenSolaris 2008.11 while runing as a guest OS on VMWare 3.5 ESX Update 3. The first time the image is booted evrything works fine, while on the next reboot(s) the error message


WARNING: Time-of-day chip unresponsive; dead batteries? 

is observed. The reason is, the first time OpenSolaris is booted, a new file with extension .nvram is created; it represents CMOS settings and it is filled with default values. On the following boot, the changes to CMOS are persisted by writting to the file, except that OpenSolaris touches a register which causes VMWare to misbehave. This is fixed in VMWare ESX 3.5 Update 4, but if you happen to bump on this issue and feel reluctant to update, then the solution is simply to remove the .nvram file.


The main impact of this bug is the system time which is reset to the January 1st 1970, which causes extremely wierd side effects on the system. In my case I learnt it was not possible to deploy Web Space Server 10 if the installation files had a date in the future. :-) 



Comments:

Post a Comment:
Comments are closed for this entry.
About

Publishing quirks of Sun software popped up during integration.

Search

Categories
Archives
« април 2014
понутосречетпетсубнед
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today