System Controller battery (BATTERY at SC/BAT/V_BAT has exceeded low warning) failure in T-series servers.
Other Learning Articles that you may like to read
Free Courses We Offer
Paid Training Courses we Offer
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.
Importance:
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.
Note:
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 off6.) 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 System8.) Here check the date and you will notice the difference.
sc> showdate
SAT JAN 01 00:06:55 UTC 20009.) 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 :-).
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
Hi Gaurav, nopes you cant see the error in prtdiag. But you will be able to see the error messages in /var/adm/messages.
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
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.
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..