My sylog is spammed by battery threshold failure messages (Yoga Pro 9i - 16IMH9) - SOLVED

[akarypid]

Hello everyone,

I just installed Bluefin for the very first time, so totally new user and also new to atomic OS concepts.

I have a problem with my laptop which is a new model. It is a Lenovo Yoga Pro 9i 2024 model (16" version). The thing is my syslog is filled with these messages:

Apr 14 10:22:38 myhost (udev-worker)[26944]: BAT0: Process '/bin/chmod 666 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:16/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/charge_control_start_threshold' failed with exit code 1.
Apr 14 10:22:38 myhost (udev-worker)[26944]: BAT0: Process '/bin/chmod 666 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:16/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/charge_control_end_threshold' failed with exit code 1.
Apr 14 10:22:38 myhost (udev-worker)[26944]: BAT0: Process '/bin/chmod 666 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:16/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/charge_start_threshold' failed with exit code 1.
Apr 14 10:22:38 myhost (udev-worker)[26944]: BAT0: Process '/bin/chmod 666 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:16/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/charge_stop_threshold' failed with exit code 1.

This is to the tune of 30,000 lines per hour!

It seems some software is trying to configure battery charging thresholds and failing? This is what I find in that location:

root@myhost ~# ls -al /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:16/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/
total 0
drwxr-xr-x. 4 root root    0 Apr 14 00:24 ./
drwxr-xr-x. 3 root root    0 Apr 14 00:24 ../
-rw-r--r--. 1 root root 4096 Apr 14 10:24 alarm
-r--r--r--. 1 root root 4096 Apr 14 00:25 capacity
-r--r--r--. 1 root root 4096 Apr 14 10:24 capacity_level
-r--r--r--. 1 root root 4096 Apr 14 00:25 cycle_count
lrwxrwxrwx. 1 root root    0 Apr 14 10:24 device -> ../../../PNP0C0A:00/
-r--r--r--. 1 root root 4096 Apr 14 00:25 energy_full
-r--r--r--. 1 root root 4096 Apr 14 00:25 energy_full_design
-r--r--r--. 1 root root 4096 Apr 14 00:25 energy_now
drwxr-xr-x. 3 root root    0 Apr 14 00:24 hwmon2/
-r--r--r--. 1 root root 4096 Apr 14 00:25 manufacturer
-r--r--r--. 1 root root 4096 Apr 14 00:25 model_name
drwxr-xr-x. 2 root root    0 Apr 14 10:24 power/
-r--r--r--. 1 root root 4096 Apr 14 00:25 power_now
-r--r--r--. 1 root root 4096 Apr 14 00:25 present
-r--r--r--. 1 root root 4096 Apr 14 00:25 serial_number
-r--r--r--. 1 root root 4096 Apr 14 00:25 status
lrwxrwxrwx. 1 root root    0 Apr 14 00:24 subsystem -> ../../../../../../../../../class/power_supply/
-r--r--r--. 1 root root 4096 Apr 14 00:25 technology
-r--r--r--. 1 root root 4096 Apr 14 00:25 type
-rw-r--r--. 1 root root 4096 Apr 14 00:24 uevent
-r--r--r--. 1 root root 4096 Apr 14 00:25 voltage_min_design
-r--r--r--. 1 root root 4096 Apr 14 00:25 voltage_now

Since I am new to this, I am not sure if this is the sort of forum to discuss what seems to be kernel/driver issues. Is Bluefin a derivative of Silverblue or is it completely independent? Would this also occur on Silverblue as the core OS and kernels are identical, or does Bluefin deviate and thus needs to be discussed here?

Thanks!

[stego]

What happens when you run the following commands as root?

chmod 666 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:16/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/charge_control_start_threshold 
chmod 666 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:16/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/charge_control_end_threshold

[akarypid]

Hello @stego !

I listed the contents of the directory above: the two files do NOT exist so the command fails with “No such file or directory”.

This is my kernel info:

~# uname -a
Linux myhost 6.8.4-100.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr  4 20:40:57 UTC 2024 x86_64 GNU/Linux

# cat /etc/redhat-release 
Fedora release 38 (Thirty Eight)

I’m a bit surprised this is based on Fedora 38. I am pretty sure I downloaded the Beta image so was expecting 40, though the kernel is a somewhat reasonably new version. Do I need to download a newer bluefin image?

Excuse my ignorance, I am quite new to bluefin…

[stego]

what does rpm-ostree status say?

btw. my /etc/redhat-release on Bluefin says Fedora release 39 (Thirty Nine)

[akarypid]

Here is the output:

~# rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run 2h 0min ago
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:gts
                   Digest: sha256:5034d6d799ecc2fcbe13a5b39d756fe1f63ae8651fef68054e7955869586da3b
                  Version: 38.20240413.0 (2024-04-13T23:31:15Z)
          LayeredPackages: oddjob-mkhomedir

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:gts
                   Digest: sha256:3447e938a01c83287dda8953865ebcb7102f70d506bf57ee0f4464569f657184
                  Version: 38.20240413.0 (2024-04-13T23:16:38Z)
          LayeredPackages: oddjob-mkhomedir

I did install the extra package oddjob-mkhomedir because I run a “home” AD domain using Samba and wanted to be able to join domain. That is the only extra addition.

[akarypid]

By the way, I downloaded my ISO for installation from https://projectbluefin.io/

I selected these options:

• What hardware are you using? → “Other laptop”
• Are you a developer? → “Yes”
• Who is the vendor of your primary GPU? → “Nvidia”

This provided this link for the ISO download: https://download.projectbluefin.io/bluefin-dx-nvidia-gts.iso

And this SHA256 hash:

9660715b100705b0bd2f27f637858e6ab2e63b7b36c26d19890d6edaccf2dccb  bluefin-dx-nvidia-gts.iso

[akarypid]

Ok I think the installer I used may be a bit out-of-date. I found this thread:

Bluefin Administration Guide

Day to Day Operation Bluefin and Aurora are designed to be installed for the life of the hardware without reinstallation. Unlike traditional operating systems the image is always pristine and “clean”, making upgrades less problematic. Updates are automatic and silent by default. Secure Boot Secure Boot is supported by default on our systems, providing an additional layer of security. After the first installation, you will be prompted to enroll the secure boot key in the BIOS. Enter the passwor…

Seems to me I should try:

rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/bluefin:latest

or even (since my laptop is quite new)

rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/bluefin:40

[stego]

rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:latest

should do the trick for you. That will install the image that is based on the current stable version (Fedora 39).

[akarypid]

Thank you @stego !

This did the trick, though I opted to go for the bleeding edge version 40 (hoping it might have newer drivers).

The good news is that the message only shows 6 times now. Obviously the charging threshold files are still missing, so apparently my laptop model still doesn’t support controlling the battery charge level, but hopefully in the future drivers will be added for it.

Either way, seems like the service gives up after a few failures. so it is no longer spamming my logs:

❯ rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin:40
                   Digest: sha256:4f5e410a355f3a07bf7fe9d625107aa7b385986d4952a59564be42b7317211a8
                  Version: 40.20240413.0 (2024-04-13T23:27:40Z)
          LayeredPackages: adcli oddjob-mkhomedir sssd-ad

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin:40
                   Digest: sha256:4f5e410a355f3a07bf7fe9d625107aa7b385986d4952a59564be42b7317211a8
                  Version: 40.20240413.0 (2024-04-13T23:27:40Z)
          LayeredPackages: oddjob-mkhomedir

~ 
❯ cat /etc/redhat-release 
Fedora release 40 (Forty)

----------------- only 6 messages logged:

~ 
❯ journalctl -b | grep BAT | wc -l
6

~ 
❯ journalctl -b | grep BAT | tail -n 2
Apr 14 15:02:36 myhost (udev-worker)[1174]: BAT0: Process '/bin/chmod 666 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:16/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/charge_start_threshold' failed with exit code 1.
Apr 14 15:02:36 myhost (udev-worker)[1174]: BAT0: Process '/bin/chmod 666 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:16/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/charge_stop_threshold' failed with exit code 1.

---- the six messages are after 10 minutes, so definitely gave up since 15:02:36
❯ uptime
 15:13:00 up 10 min,  1 user,  load average: 1.91, 1.98, 1.18

[akarypid]

Update: unfortunately I incorrectly reported this is fixed. Likely I checked after the laptop was fully charged OR had unplugged it.

The problem is still around in Fedora 40 and simply only occurs while the laptop is actively charging.

I’ve started a new thread with lots more info to properly discuss this.