Suddenly can't save files to /sys/class/power_supply/BAT0/ in dom0

Since this is my first post here, I’d like to thank the developers of Qubes OS for this fantastic operating system. I’ve been using it for almost 2 years and I love it.

I’m currently running Qubes 4.1. I created the following file called “charge-thresholds.service” to control the battery charging start and end thresholds
(I put this file in /etc/systemd/system of dom0):

Description=Set the charge start and end thresholds at startup.

ExecStart=/bin/sh -c “echo 75 > /sys/class/power_supply/BAT0/charge_control_start_threshold && echo 81 > /sys/class/power_supply/BAT0/charge_control_end_threshold”


This has worked for several months but recently stopped controlling the battery thresholds, and now my battery charges all the way to 100%. I first noticed the problem shortly after doing a dom0 update, but I don’t know whether this update is related to the problem.

Here’s the output from systemctl status charge-thresholds.service:

charge-thresholds.service - Set the charge start and end thresholds at startup.
Loaded: loaded (/etc/systemd/system/charge-thresholds.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2023-12-11 13:02:39 CST; 3h 27min ago
Process: 8392 ExecStart=/bin/sh -c echo 75 > /sys/class/power_supply/BAT0/charge_control_start_threshold &&
echo 80 > /sys/class/power_supply/BAT0/charge_control_end_threshold (code=exited, status=1/FAILURE)
Main PID: 8392 (code=exited, status=1/FAILURE)
CPU: 8ms

Dec 11 13:02:39 dom0 systemd[1]: Starting Set the charge start and end thresholds at startup…
Dec 11 13:02:39 dom0 sh[8392]: /bin/sh: /sys/class/power_supply/BAT0/charge_control_start_threshold: Permission denied
Dec 11 13:02:39 dom0 systemd[1]: charge-thresholds.service: Main process exited, code=exited, status=1/FAILURE
Dec 11 13:02:39 dom0 systemd[1]: charge-thresholds.service: Failed with result ‘exit-code’.
Dec 11 13:02:39 dom0 systemd[1]: Failed to start Set the charge start and end thresholds at startup…

There’s a permission denied error when it tries to create the file
/sys/class/power_supply/BAT0/charge_control_start_threshold. I tried to create the file myself using nano but again it gave a permission denied error when I tried to save the file, whether I got root permission by entering sudo -i before creating the file or entering sudo nano charge_control_start_threshold from the user account of dom0.

As a test, I navigated to the /sys/ directory in dom0 and tried to create a test file there using nano. Again I got a permission denied error when trying to save it. Next, I tried editing /etc/systemd/system/charge-thresholds.service. I was able to edit and then save this file with no problem.

So I’m able to edit and save files in the /etc/systemd/system directory but not in either the /sys/ or /sys/class/power_supply/BAT0/ directories of dom0. As I said above, my script had been working for several months prior to this recent problem. And I’ve also succeeded in manually creating and saving files in the /sys/class/power_supply/BAT0/ directory of dom0 prior to this recent problem.

I see some other warnings and errors in journalctl that might be related:

ACPI BIOS Warning (bug): Incorrect checksum in table [BGRT] - 0x92, should be 0x33 (20230628/utcksum-58)

ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - _SB_.PCI0.SATA (20230628/dskpginit-438)

[Firmware Bug]: ACPI MWAIT C-state 0x33 not supported by HW (0x1010)

hpet_acpi_add: no address or irqs in _CRS

ACPI Warning: _SB.PCI0.PEG2.DEV0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20230628/nsarguments-61)

System76 ACPI Driver: probe of 17761776:00 failed with error -17

pciback 0000:00:14:3: xen-pciback: Driver tried to write to a read-only configuration space field at offset 0x48, size 2. This may be harmless, but if you have problems with your device:
1) see permissive attribute in sysfs
2) report problems to the xen-devel mailing list along with details of your device obtained from lspci.

internal error: Unable to reset PCI device 0000:00:14.0: no FLR, PM reset or bus reset available

pciback 0000:00:14.0: xen_pciback: cannot enable memory-write-invalidate (-22)

I updated the firmware on this machine after noticing the problem but it didn’t make a difference.

My research seems to indicate that the problem is related to ACPI rather than xen-pciback, so I’m not including the output of lspci. I can do so if necessary, though.

Update: after composing this post I noticed that I can no longer turn on the keyboard backlight either. I believe this is also related to ACPI.

I’d appreciate it if anyone can help me to resolve these problems so I can once again set the battery charging start and end thresholds and control the keyboard backlight.

There should be some issue with your hardware and this new kernel.
Search for the issues with this kernel version used on your hardware.

Thank you for the help, apparatus. I followed the instructions for changing the default kernel here:

I changed from kernel-latest 6.6.2-1 to kernel-latest 6.5.8-1, which solved the battery charging threshold problem. It didn’t fix the keyboard backlight problem, however. I don’t use that feature very often so I suspect that some previous kernel update broke it. Probably changing to an even earlier kernel would solve it, and maybe I’ll try that later.

With 4.1 threshold files were there but with 4.2 there are no files for that.
As I fresh installed 4.2, the kernel kernel-6.1.62-1.qubes.fc37.x86_64
It seemed that the hardware (librem 14) has kept the old threshold of 4.1 but I cannot change it any more…
I just switched to 6.5.8-1 as “qubeuser” did, but no changes. I still cannot create the files int BAT0, even with root.
Any idea how to fix that. Should I downgrade to a

Check if it’s possible to change threshold on non-Qubes system (e.g. try to boot from Fedora LiveUSB). If it’s not possible there as well then it’s not a Qubes OS bug and it’d be faster to search for solution in other places (Purism forum, Fedora forum, kernel mailing list).

Thanks. Not very comfortable but Good idea!