System Controller battery (BATTERY at SC/BAT/V_BAT has exceeded low warning) failure in T-series servers.

System Controller battery (BATTERY at SC/BAT/V_BAT has exceeded low warning) failure in T-series servers.

Many a times you will get a hardware error in /var/adm/messages (or at ALOM/LOM prompt, console messages) for SC battery failure, In this post I will explain the battery replacement procedure along with its importance in the system.

sc> showfaults -v
Last POST run: THU AUG 09 11:08:20 2012
POST status: Passed all devices

  ID Time              FRU               Fault
   0 AUG 09 11:05:54   SC/BAT            BATTERY at SC/BAT/V_BAT has exceeded low warning threshold.


Battery in T-series model is located on System Controller (SC) and system downtime is required to replace the battery.

The system controller contains the persistent storage for the host ID and Ethernet MAC addresses of the system, as well as the ALOM CMT configuration including the IP addresses and ALOM CMT user accounts, if configured.

Battery provides power to the System Controller NVRAM when no AC power  is applied to the system.


After SC battery replacement the date/time on the SC/host will set to default value as shown below, the same will reflect in the hosts UPTIME too if you wont set the date/time correctly after battery replacement:

sc> showdate
SAT JAN 01 00:06:55 UTC 2000

Procedure for Battery replacement:

1.) Take the necessary outputs of the box.

2.) Run explorer before proceeding with the task (best practise).

3.) Check the error logs in /var/adm/messages and at LOM/ALOM prompt.

4.) Shutdown the box as server need to be completely down for this task.

Note: Ask Application and Database champs to bring down their applications and DB’s on the box first.

# init 5

5.) Go to LOM/ALOM using #. (hash + dot) combination and check server power state.

sc> poweroff -y
Host system power is already off

6.) Ask Hardware Engineer to repalce the battery and poweron the box so that you can get the LOM/ALOM prompt.

7.) After login into the LOM/ALOM prompt, check the hardware status to confirm all is okay.

sc> showfaults -v
No failures found in System

8.) Here check the date and you will notice the difference.

sc> showdate
SAT JAN 01 00:06:55 UTC 2000

9.) Now if you will boot the system without any change in the date/time you will get wrong uptime at server level. I will show you the wrong uptime at the server level as it needs complete reset to reflect the changes at OS level which I will perform at last (i.e server reboot).

setdate <[mmdd]HHMM | mmddHHMM[cc]yy][.SS]>

sc> setdate 09050529

sc> showdate
TUE SEP 05 05:29:35 UTC 2000

10.) Now I will poweron the box and will show you the incorrect uptime.

sc> poweron -c
Enter #. to return to ALOM.

11.) Login into the server to check the uptime.

root@test# uptime
  5:38am  up 4631 day(s),  4:05,  2 users,  load average: 0.26, 0.52, 0.28

12.) To reflect the correct uptime, the system need reboot.

root@test# init 6

13.) Now the server will come up with the correct uptime i.e synced with the NTP servers.

root@test# uptime
  5:44am  up 1 min(s),  1 user,  load average: 1.28, 0.43, 0.16

14.) Handover the box to Database and application chaps.

NOTE: Make sure you would have console and LOM/ALOM login credentials with you :-).

Yogesh Raheja

Yogesh working as a Consultant in Unix Engineering by profession. And he has multiple years experience in Solaris, Linux , AIX and Veritas Administration. He has been certified for SCSA9, SCSA10, SCNA10, VXVM, VCS, ITILv3. He is very much passionate about sharing his knowledge with others. Specialties: Expertize in Unix/Solaris Server, Linux (RHEL), AIX, Veritas Volume Manager, ZFS, Liveupgrades, Storage Migrations, Cluster deployment (VCS and HACMP) and administration and upgrade on Banking, Telecom, IT Infrastructure, and Hosting Services.

5 Responses

  1. Gaurav says:

    good Article, It will help in daily routine for replacing battery on many Solaris boxes.

    we can also see output of failed battery in prtdiag -v also

  2. Yogesh Raheja says:

    Hi Gaurav, nopes you cant see the error in prtdiag. But you will be able to see the error messages in /var/adm/messages.

  3. Vinit garg says:

    Hi,here i have one confusion, After poweron the server when we execute uptime it shows 4631 days,Now my question is from where uptime command getting this info,Isn’t it getting this info from SC card & what exactly happened after reboot that it started showing correct time.Also if we are using NTP then we shouldn’t set time in server it will automatically will be in sync when OS will be up.Please explain

  4. Ramdev Ramdev says:

    Hi Vinit, every machine , at motherboard level, will a hardware system clock supported by a battery.  

               Whenever we first install the machine ( i mean hardware), the system hardware clock will keep tickining-on as long as the supporting battery alive. And during the time ,  if there is an OS configured on that machine, OS uses the hardware clock time as OS time. And whenever  we  power-on / shutdown the system, the OS will log the time in the internal OS logs….. Uptime actually calculates the time by comparing the current time with the actual boot time ( logged inside the wtmpx). 

    >> when the network operating systems like windows/solaris/linux configured as ntp clients, during their boot they will pick up the ntp  time and will set their current time to ntp server time, instead of using hardware clock. 

  5. Vinit garg says:

    Ram still confused….:(:(
    Let’s take step by step,Suppose at 10pm I run poweroff -y ,Now as per Your saying OS will log the 10pm timing info in it’s wtmpx file .
    Suppose It took 1 hr to replace the battery & at 11pm I execute poweron -c then again as soon as OS will come up it will log the 11pm timing info in it’s wtmpx file So when we will run uptime then it must show it’s correct timing as wtmpx is now updated..

What is in your mind, about this post ? Leave a Reply

  Our next learning article is ready, subscribe it in your email

What is your Learning Goal for Next Six Months ? Talk to us