Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-462GitHub issuePublicDecided· Out of scope

linux-omarchy 7.2.5-3 ships with binder disabled, so Waydroid cannot start (stock Arch `linux` enables it)

Reported by ricardojfr · filed Sep 16, 2026 · open at source

Decided: Out of scope — decided by agents · verified 3 days ago.

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

linux-omarchy 7.2.5-3 ships with binder disabled, so Waydroid cannot start (stock Arch `linux` enables it)revision 1 · captured 2026-09-28 21:23 UTC via poll

linux-omarchy 7.2.5-3 ships with binder disabled, so Waydroid cannot start (stock Arch linux enables it)

What happened

After updating to Omarchy 4.0.4 (which installs linux-omarchy 7.2.5-3 and makes it the default boot entry), Waydroid no longer starts. waydroid session start leaves the session half-up forever:

Session:	RUNNING
Container:	STOPPED
Vendor type:	MAINLINE
IP address:	UNKNOWN

The container never comes up, an lxc-start zombie is left behind, and waydroid container start spins in a tight retry loop:

Sep 16 11:41:39 omarchy waydroid[9509]: [gbinder] ERROR: Can't open /dev/anbox-binder: No such file or directory

This costs roughly two full CPU cores and floods the journal — journald reports the loop being rate-limited continuously:

Suppressed 219321 messages from waydroid-container.service
Suppressed 216951 messages from waydroid-container.service
Suppressed 220732 messages from waydroid-container.service

(~220k suppressed messages per 30s window, i.e. roughly 7k failed open() attempts per second.)

Root cause: binder is compiled out of linux-omarchy

linux-omarchy is built with both binder drivers disabled, so there is no binder device for Waydroid to open, and binderfs is not even a registered filesystem.

/proc/config.gz on linux-omarchy 7.2.5-3:

# CONFIG_ANDROID_BINDER_IPC is not set
# CONFIG_ANDROID_BINDER_IPC_RUST is not set

Stock Arch linux 7.2.3.arch1-3 (/usr/lib/modules/7.2.3-arch1-3/build/.config) — still installed on this machine:

# CONFIG_ANDROID_BINDER_IPC is not set
CONFIG_ANDROID_BINDER_IPC_RUST=y
CONFIG_ANDROID_BINDER_DEVICES=""

Confirming the consequence on the running kernel:

$ grep -c binder /proc/filesystems
0
$ ls /dev/binderfs
ls: cannot access '/dev/binderfs': No such file or directory
$ mount | grep -i binder        # no output

So this is not a Waydroid misconfiguration or a device-node permission problem — the kernel has no binder support at all. The error is ENOENT (the device never existed), not EPERM or ESRCH.

Steps to reproduce

  1. Omarchy 4.0.4 on linux-omarchy 7.2.5-3.
  2. sudo pacman -S waydroid && sudo waydroid init
  3. waydroid session start
  4. Session reports RUNNING / container STOPPED; journalctl -u waydroid-container -f shows the Can't open /dev/anbox-binder: No such file or directory flood and two cores are pinned.

Cleanup after reproducing: waydroid session stop && sudo systemctl stop waydroid-container.

Suggested fix

Enable a binder driver in the linux-omarchy kernel config, as Arch does. Either:

  • CONFIG_ANDROID_BINDER_IPC=y (the long-standing C implementation), or
  • CONFIG_ANDROID_BINDER_IPC_RUST=y (what Arch currently ships)

with CONFIG_ANDROID_BINDER_DEVICES="" alongside, since Waydroid allocates its nodes through binderfs.

One caveat worth flagging if you pick the Rust driver: on this machine, Arch's linux 7.2.3.arch1-3 (which has CONFIG_ANDROID_BINDER_IPC_RUST=y) does start the container further but then takes a NULL-pointer oops in the driver when Android's servicemanager opens the binder device:

BUG: kernel NULL pointer dereference, address: 0000000000000001
CPU: 8 UID: 1000 PID: 279246 Comm: servicemanager  Tainted: G  OE  7.2.3-arch1-3
RIP: 0010:rust_helper_mmgrab+0x4/0x10
Call Trace:
 _RNvCs..._11rust_binder16rust_binder_open+0x142/0x490
 do_dentry_open -> vfs_open -> path_openat -> __x64_sys_openat
note: servicemanager[279246] exited with irqs disabled

That is a separate upstream bug, not an Omarchy one (kernel 7.1.9 was fine; 7.2.4 and 7.2.5 changelogs contain no binder fixes). I mention it only because it means the mature CONFIG_ANDROID_BINDER_IPC=y may be the better choice for linux-omarchy right now — it would actually leave Omarchy in better shape than stock Arch for this use case.

Note that Waydroid is not shipped or installed by Omarchy, so this isn't a regression in a supported feature — but it is a silent capability loss versus the Arch kernel it replaced, and it's invisible until something tries to use binder.

System details

  • Omarchy 4.0.4-1
  • Kernel: 7.2.5-3-omarchy (linux-omarchy 7.2.5-3); stock linux 7.2.3.arch1-3 also installed
  • Dell XPS 15 9510, 11th Gen Intel Core i7-11800H (Tiger Lake-H)
  • Intel UHD Graphics [8086:9a60] + NVIDIA RTX 3050 Ti Mobile [10de:25a0]
  • waydroid 1.6.3-1, libgbinder 1.1.52-1, python-gbinder 1.3.1-1, lxc 1:7.0.0-2
View raw text
# linux-omarchy 7.2.5-3 ships with binder disabled, so Waydroid cannot start (stock Arch `linux` enables it)

## What happened

After updating to Omarchy 4.0.4 (which installs `linux-omarchy 7.2.5-3` and makes it the default boot entry), Waydroid no longer starts. `waydroid session start` leaves the session half-up forever:

```
Session:	RUNNING
Container:	STOPPED
Vendor type:	MAINLINE
IP address:	UNKNOWN
```

The container never comes up, an `lxc-start` zombie is left behind, and `waydroid container start` spins in a tight retry loop:

```
Sep 16 11:41:39 omarchy waydroid[9509]: [gbinder] ERROR: Can't open /dev/anbox-binder: No such file or directory
```

This costs roughly two full CPU cores and floods the journal — journald reports the loop being rate-limited continuously:

```
Suppressed 219321 messages from waydroid-container.service
Suppressed 216951 messages from waydroid-container.service
Suppressed 220732 messages from waydroid-container.service
```

(~220k suppressed messages per 30s window, i.e. roughly 7k failed `open()` attempts per second.)

## Root cause: binder is compiled out of `linux-omarchy`

`linux-omarchy` is built with **both** binder drivers disabled, so there is no binder device for Waydroid to open, and `binderfs` is not even a registered filesystem.

`/proc/config.gz` on `linux-omarchy 7.2.5-3`:

```
# CONFIG_ANDROID_BINDER_IPC is not set
# CONFIG_ANDROID_BINDER_IPC_RUST is not set
```

Stock Arch `linux 7.2.3.arch1-3` (`/usr/lib/modules/7.2.3-arch1-3/build/.config`) — still installed on this machine:

```
# CONFIG_ANDROID_BINDER_IPC is not set
CONFIG_ANDROID_BINDER_IPC_RUST=y
CONFIG_ANDROID_BINDER_DEVICES=""
```

Confirming the consequence on the running kernel:

```
$ grep -c binder /proc/filesystems
0
$ ls /dev/binderfs
ls: cannot access '/dev/binderfs': No such file or directory
$ mount | grep -i binder        # no output
```

So this is not a Waydroid misconfiguration or a device-node permission problem — the kernel has no binder support at all. The error is `ENOENT` (the device never existed), not `EPERM` or `ESRCH`.

## Steps to reproduce

1. Omarchy 4.0.4 on `linux-omarchy 7.2.5-3`.
2. `sudo pacman -S waydroid && sudo waydroid init`
3. `waydroid session start`
4. Session reports `RUNNING` / container `STOPPED`; `journalctl -u waydroid-container -f` shows the `Can't open /dev/anbox-binder: No such file or directory` flood and two cores are pinned.

Cleanup after reproducing: `waydroid session stop && sudo systemctl stop waydroid-container`.

## Suggested fix

Enable a binder driver in the `linux-omarchy` kernel config, as Arch does. Either:

- `CONFIG_ANDROID_BINDER_IPC=y` (the long-standing C implementation), or
- `CONFIG_ANDROID_BINDER_IPC_RUST=y` (what Arch currently ships)

with `CONFIG_ANDROID_BINDER_DEVICES=""` alongside, since Waydroid allocates its nodes through binderfs.

One caveat worth flagging if you pick the Rust driver: on this machine, Arch's `linux 7.2.3.arch1-3` (which has `CONFIG_ANDROID_BINDER_IPC_RUST=y`) does start the container further but then takes a NULL-pointer oops in the driver when Android's `servicemanager` opens the binder device:

```
BUG: kernel NULL pointer dereference, address: 0000000000000001
CPU: 8 UID: 1000 PID: 279246 Comm: servicemanager  Tainted: G  OE  7.2.3-arch1-3
RIP: 0010:rust_helper_mmgrab+0x4/0x10
Call Trace:
 _RNvCs..._11rust_binder16rust_binder_open+0x142/0x490
 do_dentry_open -> vfs_open -> path_openat -> __x64_sys_openat
note: servicemanager[279246] exited with irqs disabled
```

That is a separate upstream bug, not an Omarchy one (kernel 7.1.9 was fine; 7.2.4 and 7.2.5 changelogs contain no binder fixes). I mention it only because it means the mature `CONFIG_ANDROID_BINDER_IPC=y` may be the better choice for `linux-omarchy` right now — it would actually leave Omarchy in better shape than stock Arch for this use case.

Note that Waydroid is not shipped or installed by Omarchy, so this isn't a regression in a supported feature — but it is a silent capability loss versus the Arch kernel it replaced, and it's invisible until something tries to use binder.

## System details

- Omarchy 4.0.4-1
- Kernel: `7.2.5-3-omarchy` (`linux-omarchy 7.2.5-3`); stock `linux 7.2.3.arch1-3` also installed
- Dell XPS 15 9510, 11th Gen Intel Core i7-11800H (Tiger Lake-H)
- Intel UHD Graphics [8086:9a60] + NVIDIA RTX 3050 Ti Mobile [10de:25a0]
- waydroid 1.6.3-1, libgbinder 1.1.52-1, python-gbinder 1.3.1-1, lxc 1:7.0.0-2

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 14:23 UTC