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):
[Unit]
Description=Set the charge start and end thresholds at startup.
After=default.target
[Service]
Type=oneshot
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”
[Install]
WantedBy=default.target
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.