Librem 14 Failed to charge SOLVED

Great thank you I’m good then.

There is a script that Purism made you can use, which will use wget to pull down the source, and then compile it on your local machine regardless of the distro. Just search ‘coreboot script’ on this forum and you’ll find the thread on it.

If you do not have PureOS installed, then boot from a PureOS live ISO with Byzantum:

And folow the instructions here to update Pureboot/coreboot

1 Like


I have the same problem using Fedora 34 (kernel 5.12.14-300) so I can not install librem-ec-acpi-dkms using apt.

I tried to clone then build the source, but I encountered the following error.

sudo dnf groupinstall "Development Tools" "Development Libraries"
git clone
cd librem-ec-acpi-dkms
sudo make all

arch/x86/Makefile:126: *** Recursive variable 'KBUILD_CFLAGS' references itself (eventually).  Stop.
make[1]: *** [Makefile:1860: arch/x86] Error 2
make[1]: Leaving directory '/usr/src/kernels/5.12.14-300.fc34.x86_64'
make: *** [Makefile:5: all] Error 2

I don’t know what to do. Also, I am a bit suprised that the computer not charging when it is off, so maybe this is not a software issue in my case?

Hello @nicole.faerber, I am sorry to ping you, but I didn’t received any feedback on this issue (not even from the support) and I feel stuck here. Should I open an issue on the repository instead? Let me know how can I help. Thank you.

Hi, may I suggest a different approach to try to install the driver in Fedora.

You can try to convert the DEB package into a an RPM package that you can install with dnf.

To do this:

  • Install the package alien in Fedora:

sudo dnf install alien

  • Download a copy of the deb package from here:

  • To convert the package into an RPM package, from the same directory to where you downloaded the deb package, run the command:

sudo alien -r --scripts librem-ec-acpi-dkms_0.9.1-1~pureos1_all.deb

  • This will generate the package:


  • That you can install using dnf;

sudo dnf install ./librem-ec-acpi-dkms-0.9.1-2.noarch.rpm

And then reboot. Then please list here the files under:


I tried this method in a VM with fedora 34 latest kernel. And the driver installed.

But since it was not a baremetal install there was no battery settings for me to check

1 Like

Thank you @joao.azevedo for your help.

I have followed your instructions, the package seems to be correctly installed.

sudo dnf list --installed | grep librem
librem-ec-acpi-dkms.noarch        0.9.1-2        @@commandline 

But after reboot, I still don’t have the charge_control_start_threshold file.

ls -l /sys/class/power_supply/BAT0/
total 0
-rw-r--r--. 1 root root 4096 Jul 29 13:56 alarm
-r--r--r--. 1 root root 4096 Jul 29 13:51 capacity
-r--r--r--. 1 root root 4096 Jul 29 13:56 capacity_level
-r--r--r--. 1 root root 4096 Jul 29 13:51 charge_full
-r--r--r--. 1 root root 4096 Jul 29 13:51 charge_full_design
-r--r--r--. 1 root root 4096 Jul 29 13:51 charge_now
-r--r--r--. 1 root root 4096 Jul 29 13:51 current_now
-r--r--r--. 1 root root 4096 Jul 29 13:56 cycle_count
lrwxrwxrwx. 1 root root    0 Jul 29 13:56 device -> ../../../PNP0C0A:00
drwxr-xr-x. 3 root root    0 Jul 29 13:51 hwmon1
-r--r--r--. 1 root root 4096 Jul 29 13:51 manufacturer
-r--r--r--. 1 root root 4096 Jul 29 13:51 model_name
drwxr-xr-x. 2 root root    0 Jul 29 13:56 power
-r--r--r--. 1 root root 4096 Jul 29 13:51 present
-r--r--r--. 1 root root 4096 Jul 29 13:51 serial_number
-r--r--r--. 1 root root 4096 Jul 29 13:51 status
lrwxrwxrwx. 1 root root    0 Jul 29 13:51 subsystem -> ../../../../../../class/power_supply
-r--r--r--. 1 root root 4096 Jul 29 13:51 technology
-r--r--r--. 1 root root 4096 Jul 29 13:51 type
-rw-r--r--. 1 root root 4096 Jul 29 13:51 uevent
-r--r--r--. 1 root root 4096 Jul 29 13:51 voltage_min_design
-r--r--r--. 1 root root 4096 Jul 29 13:51 voltage_now

After installing acpi… I’m having those 2 files.
I changed to 45 and 95 but I’m stuck at 69 % all the time [with charger in it … if I’ll remove the charger then it will go down]

I have done all the fixes, and the settings as directed by Purism support, and mine charges now just fine. I will note however that even though the upper threshold says 95, it will always charge to 100% if allowed.

I am having the same problem with my new L14. If I follow these steps from a PureOS live disk, will these settings be carried over to my Qubes installation (i.e. are the /sys files updated on the firmware itself when I apply the fix)?

yes, because the values are saved in the EC’s battery-backed RAM (BRAM). As long as the internal battery isn’t disconnected, the settings will persist until overridden externally


Finally the solution provided by the support was to install the firmware using dkms instead of make (for non Debian distributions).

After cloning or downloading the source from the link provided by the support, follow instructions below.

Copy the Debian dkms.conf to the root of the source directory:

cp debian/librem-ec-acpi-dkms.dkms dkms.conf

Modify dkms.conf in a text editor so PACKAGE_VERSION is set to a value:


Add and build the module using dkms:

sudo dkms add ./
sudo dkms build librem_ec_acpi/1.0
sudo dkms install librem_ec_acpi/1.0

Now lsmod should show librem_ec_acpi:

lsmod | grep librem_ec_acpi
librem_ec_acpi         16384  0

You should also see new files to control the battery:

cat /sys/class/power_supply/BAT0/charge_control_start_threshold 
cat /sys/class/power_supply/BAT0/charge_control_end_threshold

Thank you @joao.azevedo :slightly_smiling_face:

there are already some non Debian distributions that have it packaged.

And there are some instructions for QubesOS:

And the librem-ec-acpi is now in Debian Experimental, so “soonish” it should start entering the DEB “world”

Check with the system monitor as stated in Youtube tutorial

I had to set the start and end thresholds again after installing the latest (4.14-Purism-1) coreboot update. The start was back to 0. Is there a plan to make the user defined battery charging settings persistent over the coreboot update?

1 Like

@MrChromebox ^^ :point_up:

1 Like

coreboot has nothing to do with the EC battery thresholds, updating coreboot would not change/clear them.

The most recent EC firmware update sets these to 90/100 as the default, so they should not reset back to 0/100 ever after applying it

@MrChromebox Thank you for the clarification. In that case I wonder what I did so these thresholds were reset. What I know I did was update coreboot with the coreboot utility script. And of course updates with apt. Could the latter have caused the reset?

if the kernel got updated, possible the EC driver did not persist across?

I do not know enough to answer that question… what I can say, is that I used the option to compile the update locally.