Updater fails battery checks on a machine without a battery

[castrojo]

On my bluefin:38 machine:

Oct 04 18:33:37 exo systemd[1]: Failed to start ublue-update.service - Universal Blue Update Oneshot Service.
Oct 04 18:33:37 exo systemd[1]: ublue-update.service: Failed with result 'exit-code'.
Oct 04 18:33:37 exo systemd[1]: ublue-update.service: Main process exited, code=exited, status=1/FAILURE
Oct 04 18:33:37 exo ublue-update[14453]:  - Battery less than 50.0%
Oct 04 18:33:37 exo ublue-update[14453]: Exception: update failed to pass checks:
Oct 04 18:33:37 exo ublue-update[14453]:     raise Exception(f"update failed to pass checks: \n - {exception_log}")
Oct 04 18:33:37 exo ublue-update[14453]:   File "/usr/lib/python3.12/site-packages/ublue_update/cli.py", line 96, in hardware_inhibitor_checks_failed
Oct 04 18:33:37 exo ublue-update[14453]:     hardware_inhibitor_checks_failed(
Oct 04 18:33:37 exo ublue-update[14453]:   File "/usr/lib/python3.12/site-packages/ublue_update/cli.py", line 247, in main
Oct 04 18:33:37 exo ublue-update[14453]:              ^^^^^^
Oct 04 18:33:37 exo ublue-update[14453]:     sys.exit(main())
Oct 04 18:33:37 exo ublue-update[14453]:   File "/usr/bin/ublue-update", line 8, in <module>
Oct 04 18:33:37 exo ublue-update[14453]: Traceback (most recent call last):
Oct 04 18:33:37 exo ublue-update[14453]: [2023-10-04 18:33:37,034] ublue_update.cli:INFO | No updates are available.
Oct 04 18:33:37 exo ublue-update[14453]: [2023-10-04 18:33:37,034] ublue_update.update_checks.system:INFO | No system update available.

[bobslept]

Do you by any chance use a wireless mouse?

My machine without battery returns None by the following command. Can you run this command and post the output?

echo -e "import psutil\nprint(psutil.sensors_battery())" | python

And output of ls /sys/class/power_supply/*

Probably there is a device with a battery being used, that is recognized as a "main" battery by the script.

[castrojo]

I do have a wireless mouse!

echo -e "import psutil\nprint(psutil.sensors_battery())" | python
sbattery(percent=23, secsleft=<BatteryTime.POWER_TIME_UNKNOWN: -1>, power_plugged=False)

and

ls /sys/class/power_supply/*
capacity      model_name  scope          type
device        online      serial_number  uevent
hwmon7        power       status         voltage_now
manufacturer  powers      subsystem      wakeup78

[bobslept]

Can you do a grep -r . /sys/class/power_supply/ too? Problem with this stuff is that there quiet a few of these kind of devices with a battery, that can show up. So you probably want some kind of filter or something.

[castrojo]

I have one item in there:

❯ ls -l
lrwxrwxrwx@ - root  5 Oct 13:11 hidpp_battery_0 -> ../../devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:10:00.0/usb5/5-4/5-4:1.2/0003:046D:C539.0008/0003:046D:4079.0011/power_supply/hidpp_battery_0

[bobslept]

For example TLP is doing the same, it's ignoring exactly the one you are posting in their "ignore" list.

https://github.com/linrunner/TLP/blob/40c44d108182fd57c2ff44d685a8f908a9c782d3/tlp-func-base.in#L51C1-L52

# power supplies: ignore MacBook Pro 2017 sbs-charger and hid devices
readonly RE_PS_IGNORE='sbs-charger|hidpp_battery|hid-'

[castrojo]

Maybe we should skip the battery thing in bluefin entirely and just avoid having to special case a bunch of hardware?

[bobslept]

Can you verify that ublue-update runs correctly if you set min_battery_percent = 0 in the config toml? That should "skip" the check.

Alright that seems to work!

[gerblesh]

unfortunately this is an upstream issue with psutil, the relevant PR is here:
giampaolo/psutil#2305