Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
omarchy-battery-status shows 0W when power_now exists but returns ENODEV, clobbering good UPower rate
Reported by connormcharg · filed Sep 21, 2026Closed upstream on 2026-10-12 by the bot omarchybot, as a duplicate of #6895 (R-1854). GitHub close reason: duplicate.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
What happened:omarchy battery status shows 0W while discharging, even though UPower knows the real rate. Time-left is correct, only wattage is wrong:
- omarchy battery status → Battery 94% · 6h 54m left · 0W / 40Wh
- omarchy battery status --shell → rate 0W, time 6h 54m
- upower -i → energy-rate: 5.51928 W, time to empty: 6.9 hours, percentage: 94%
What was expected:
Wattage should show ~5.5W (the UPower value), not 0W.
Steps to reproduce:
1. On a machine where /sys/class/power_supply/BAT0/power_now exists but reads fail with No such device, and current_now is absent (HP Pavilion 15-eh1xxx here).
2. Unplug AC so battery is Discharging.
3. Run omarchy battery status and compare with upower -i $(upower -e | grep BAT).
Root cause:
In omarchy-battery-status, the UPower rate is unconditionally overwritten when the sysfs node merely passes [[ -r … ]]:
if [[ -r $battery_path/power_now ]]; then
power_rate_raw=$(awk -v microwatts="$(<"$battery_path/power_now")" 'BEGIN { print microwatts / 1000000 }')On this machine -r is true, but the read fails with ENODEV, so microwatts is empty and awk yields 0, clobbering the good 5.5W from UPower. Same hazard applies to the current_now/voltage_now branch.
Suggested fix:
Only override when the sysfs read actually succeeds and is numeric, e.g.:
if microwatts=$(cat "$battery_path/power_now" 2>/dev/null) && [[ $microwatts =~ ^[0-9]+$ ]]; then
power_rate_raw=$(awk -v microwatts="$microwatts" 'BEGIN { print microwatts / 1000000 }')
elif ...System details:
- Omarchy: 4.0.4-1
- Kernel: 7.2.5-3-omarchy
- Laptop: HP Pavilion Laptop 15-eh1xxx, BIOS F.34 (03/30/2026)
- CPU: AMD Ryzen 5 5500U with Radeon Graphics
- GPU: AMD/ATI Lucienne
- Battery: BAT0, HP Primary, 16 cycles, energy_full=40574000, energy_now dropping normally after update
Diagnostics:
$ cat /sys/class/power_supply/BAT0/power_now
cat: /sys/class/power_supply/BAT0/power_now: No such device
$ ls /sys/class/power_supply/BAT0/
alarm capacity capacity_level cycle_count device energy_full energy_full_design energy_now extensions hwmon2 manufacturer model_name power power_now present serial_number status subsystem technology type uevent voltage_min_design voltage_now
$ cat /sys/class/power_supply/BAT0/hwmon2/power1_input
cat: .../power1_input: No such deviceNote: omarchy debug --no-sudo --print / omarchy debug does not exist in 4.0.4-1 (Unknown Omarchy command), so no debug log attached — happy to provide whatever the current equivalent is.
View raw text
What happened:
`omarchy battery status` shows `0W` while discharging, even though UPower knows the real rate. Time-left is correct, only wattage is wrong:
- `omarchy battery status` → `Battery 94% · 6h 54m left · 0W / 40Wh`
- `omarchy battery status --shell` → `rate 0W`, `time 6h 54m`
- `upower -i` → `energy-rate: 5.51928 W`, `time to empty: 6.9 hours`, `percentage: 94%`
What was expected:
Wattage should show ~5.5W (the UPower value), not 0W.
Steps to reproduce:
1. On a machine where `/sys/class/power_supply/BAT0/power_now` exists but reads fail with `No such device`, and `current_now` is absent (HP Pavilion 15-eh1xxx here).
2. Unplug AC so battery is `Discharging`.
3. Run `omarchy battery status` and compare with `upower -i $(upower -e | grep BAT)`.
Root cause:
In `omarchy-battery-status`, the UPower rate is unconditionally overwritten when the sysfs node merely passes `[[ -r … ]]`:
```bash
if [[ -r $battery_path/power_now ]]; then
power_rate_raw=$(awk -v microwatts="$(<"$battery_path/power_now")" 'BEGIN { print microwatts / 1000000 }')
```
On this machine `-r` is true, but the read fails with ENODEV, so `microwatts` is empty and awk yields `0`, clobbering the good `5.5W` from UPower. Same hazard applies to the `current_now`/`voltage_now` branch.
Suggested fix:
Only override when the sysfs read actually succeeds and is numeric, e.g.:
```bash
if microwatts=$(cat "$battery_path/power_now" 2>/dev/null) && [[ $microwatts =~ ^[0-9]+$ ]]; then
power_rate_raw=$(awk -v microwatts="$microwatts" 'BEGIN { print microwatts / 1000000 }')
elif ...
```
System details:
- Omarchy: 4.0.4-1
- Kernel: 7.2.5-3-omarchy
- Laptop: HP Pavilion Laptop 15-eh1xxx, BIOS F.34 (03/30/2026)
- CPU: AMD Ryzen 5 5500U with Radeon Graphics
- GPU: AMD/ATI Lucienne
- Battery: BAT0, HP Primary, 16 cycles, `energy_full=40574000`, `energy_now` dropping normally after update
Diagnostics:
```
$ cat /sys/class/power_supply/BAT0/power_now
cat: /sys/class/power_supply/BAT0/power_now: No such device
$ ls /sys/class/power_supply/BAT0/
alarm capacity capacity_level cycle_count device energy_full energy_full_design energy_now extensions hwmon2 manufacturer model_name power power_now present serial_number status subsystem technology type uevent voltage_min_design voltage_now
$ cat /sys/class/power_supply/BAT0/hwmon2/power1_input
cat: .../power1_input: No such device
```
Note: `omarchy debug --no-sudo --print` / `omarchy debug` does not exist in 4.0.4-1 (`Unknown Omarchy command`), so no debug log attached — happy to provide whatever the current equivalent is.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 16:55 UTC