18

I have found myself in situtations where the internal battery has been used frequently. How do I check its status without diving into the mountain of directories?

NOTE I need to know about the CMOS battery. not the laptop's power supply, so this isn't a duplicate of those questions

2
  • 1
    If you mean the CMOS battery, please update your question and its title to say so – “internal” is a rather puzzling term, as laptop batteries are usually internal.
    – dessert
    Commented Aug 14, 2017 at 10:10
  • 1
    Just a link cuz this is probably what you need: manpages.ubuntu.com/manpages/xenial/man4/nvram.4freebsd.html But nooooooooo idea how since it differs per system .... Edit about close votes removed; If you have complaints post that on meta.askubuntu.com and otherwise: after it is closed it can be re-opened
    – Rinzwind
    Commented Aug 14, 2017 at 10:33

5 Answers 5

12
$ cat /proc/driver/rtc | grep batt
batt_status     : okay
2
  • 2
    Relevant note: "CMOS" is a tiny bit of very low power static memory that lives on the same chip as the Real-Time Clock. It is fairly convenient to actually think of the RTC as being "part" of CMOS. -- OSDev Wiki
    – user37165
    Commented Nov 4, 2019 at 5:52
  • 1
    Tried this after removing the CMOS battery: this command still stays batt_status: okay
    – BenMorel
    Commented Mar 14 at 11:13
9

use app lm_sensors:

$ sensors-detect

next , run sensors and look for Vbat value:

$ sensors
it8718-isa-0290
Adapter: ISA adapter
in0:          +1.18 V  (min =  +0.00 V, max =  +4.08 V)
in1:          +1.89 V  (min =  +0.00 V, max =  +4.08 V)
in2:          +3.31 V  (min =  +0.00 V, max =  +4.08 V)
+5V:          +2.91 V  (min =  +0.00 V, max =  +4.08 V)
in4:          +0.69 V  (min =  +0.00 V, max =  +4.08 V)
in5:          +0.08 V  (min =  +0.00 V, max =  +4.08 V)
in6:          +0.42 V  (min =  +0.00 V, max =  +4.08 V)
in7:          +2.93 V  (min =  +0.00 V, max =  +4.08 V)
Vbat:         +2.94 V  
fan1:        1713 RPM  (min =    0 RPM)
fan2:        1558 RPM  (min =    0 RPM)
fan3:           0 RPM  (min =    0 RPM)
fan4:           0 RPM  (min =    0 RPM)
temp1:        +48.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2:        +39.0°C  (low  = +127.0°C, high = +70.0°C)  sensor = thermal diode
temp3:         -2.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
intrusion0:  ALARM

radeon-pci-0100
Adapter: PCI adapter
temp1:        +55.0°C  

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +56.0°C  (high = +80.0°C, crit = +100.0°C)
Core 1:       +55.0°C  (high = +80.0°C, crit = +100.0°C)
3
  • 3
    And which of those figures is the CMOS battery?
    – PerlDuck
    Commented Aug 23, 2018 at 9:31
  • 3
    This screen: Vbat: +2.94 V but your system it may be Battery or another, all depends from modules detected in sensors-detect
    – zersh
    Commented Aug 23, 2018 at 9:41
  • 1
    I tried that, I get multiple temp sensors and fan status. Nothing on voltages. Commented Sep 2, 2018 at 0:48
5

If you open up the laptop, you can use a multimeter to check the voltmeter reading of the CMOS battery. This is the only reliable way that I know of.

1
  • 4
    My system reported batt_status okay via /proc/driver/rtc but when I measured with voltmeter only 0.2V Commented Jan 31, 2023 at 5:59
4

The sensors command doesn't output the CMOS battery voltage for my laptop. This article gives other pointers:

To summarize the link:

A constant beeping sound is another sign that your CMOS battery is dying. The final sign that your CMOS battery is going dead is that you'll receive an error message. The three main types of error messages are: CMOS Checksum Error, CMOS Read Error and CMOS Battery Failure.

0

It seems that it can not directly detected on many systems (rtc_cmos), because the RTC time will be corrected when the kernel is loaded and the failed oscillator flag will be reset. Then the RTC is powered by the system.

Therefore the answer of Martin doesn't work, as the result is always okay on such systems.

$ cat /proc/driver/rtc | grep batt
batt_status     : okay

But the rtc driver seems to fix the time itself, some drivers would log this to the kernel log, but even when it's not logged you could determine it by verify the rtc clock setting in the log.

$ sudo journalctl -k -g rtc.*setting
Jan 26 22:48:36 pc-4711 kernel: rtc_cmos 00:00: setting system clock to 2012-01-01T00:00:30 UTC (1325376030)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .