Arch Linux User Repository

This has been adjusted to build on 5.10-5.15 thank you to legend Christian Hoff!

Working DKMS fork by Christian Hoff: https://github.com/choff/anbox-modules

DKMS add modules, without reboot:

sudo modprobe binder_linux devices=binder,hwbinder,vndbinder,anbox-binder,anbox-hwbinder,anbox-vndbinder

sudo modprobe ashmem_linux

Pull Requests: https://github.com/sickcodes/aur

Contact (Discord/Telegram/Git/Element): https://sick.codes

For build on 6.0 Kernel, I have a patch to fix binder:

diff --git a/binder/binder_alloc.c b/binder/binder_alloc.c
index 61dd545..7fe818d 100644
--- a/binder/binder_alloc.c
+++ b/binder/binder_alloc.c
@@ -23,6 +23,7 @@
 #include <linux/uaccess.h>
 #include <linux/highmem.h>
 #include <linux/sizes.h>
+#include <linux/version.h>
 #include "binder_alloc.h"
 #include "binder_trace.h"

@@ -1079,7 +1080,11 @@ int binder_alloc_shrinker_init(void)
    int ret = list_lru_init(&binder_alloc_lru);

    if (ret == 0) {
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(6,0,0))
+       ret = register_shrinker(&binder_shrinker, "binder");
+#else
        ret = register_shrinker(&binder_shrinker);
+#endif
        if (ret)
            list_lru_destroy(&binder_alloc_lru);
    }

However, I have not worked on ashmem because waydroid can use memfd instead...

Additional heads up: Building with the latest kernel and headers for aarch64 (5.19.8-1-MANJARO-ARM) does not work!

[ 219.334574] binder_linux: loading out-of-tree module taints kernel.

[ 219.334952] binder_linux: Unknown symbol __check_object_size (err -2)

[ 219.335146] binder_linux: Unknown symbol fortify_panic (err -2)

[ 219.335241] binder_linux: Unknown symbol __list_add_valid (err -2)

[ 219.335310] binder_linux: Unknown symbol __audit_inode_child (err -2)

[ 219.335337] binder_linux: Unknown symbol __list_del_entry_valid (err -2)

[ 219.335545] binder_linux: Unknown symbol register_kprobe (err -2)

[ 219.335605] binder_linux: Unknown symbol unregister_kprobe (err -2)

Heads up: it seems like aarch64 folks have to clone the package repo and build that way -- no prebuilt aarch64 package is currently available according to pacman.

https://github.com/choff/anbox-modules/pull/4

This pull request fixes building on 5.19 Kernel and has not been merged by choff. Please consider merging this pull request in PKGBUILD manually as 5.19 has been a stable kernel.

Omar007, TU Foxboron thinks it's not a VCS package, and should not be removed.

https://lists.archlinux.org/pipermail/aur-requests/2022-January/065458.html

But I agree that anbox-modules-dkms-git should be used instead.

This PKGBUILD is a bit of a mess tbh. The first thing I noticed is that a DKMS package that should just be copying files is building stuff. In the package() function... That means that it can't currently even create a package assuming you build in a clean environment/chroot (as one should..). Just that was enough for me to go over the PKGBUILD in full, which leads to the following list of problems:

• A DKMS package is attempting to make the module. And in package() of all places. It's a DKMS package. There's nothing to build here, that's where DKMS comes in after it has been installed!
• There's a double arch definition, one of which relies on the state of the packaging system?!? If any system is fine, just use arch=('any') ! Though in this case it's overwritten later anyway so it becomes completely irrelevant.
• A superfluous provides. There's no point in providing oneself.
• A conflicts that shouldn't be there. VCS variants should provide and conflict with the stable/non-VCS variant, not the other way around. And that is already properly covered by the -git variant of this package.
• User output in package(). That shouldn't be there or be put in a .INSTALL post_install/post_upgrade if it's actually relevant for the end-user.
• It's missing the rules and config files as part of the default upstream set/instructions.
• File mode while packaging is not guaranteed (though that should be fine if build in a clean chroot but clearly that isn't happening as that will break due to the first point)
• The installed module version isn't matching the package version (1 != 5.18). This discrepancy made me check the pkgver with upstream and it turns out; there is none!! The pkgver is just an arbitrary number! There is not actually a versioned variant available and it's just a randomly chosen commit (probably just w/e HEAD was at at the time of the last PKGBUILD update) and self-decided pkgver from what I can tell.

I was initially going to provide an patch for this but when I hit the last point I realized there would be no point in doing so. That last one basically means that for all intends and purposes this is basically just a VCS package, which means:

TL/DR: just use anbox-modules-dkms-git. That one solves all of these problems (except for the second to last). This package should probably be dropped from the AUR.

upstream was updated thanks to my PR, so you can remove that patch now

Hey @allsey87

Does sudo modprobe binder_linux devices=binder-control help?

Also dkms > 3.0.3 is broken https://github.com/dell/dkms/issues/229

I required a downgrade dkms temporarily.

When I try to insert binder_linux into my kernel (5.18.10-arch1-1) with modprobe, I do not get a binder-control device node under /dev/binderfs. Checking dmesg I can see that something is indeed going wrong:

traps: Missing ENDBR: kallsyms_lookup_name+0x4/0xf0

Perhaps related to: https://lwn.net/Articles/813350/ ?

I edited binder/deps.c: I had problems with compile on my Amlogic s905x3 box (5.14+ kernels..) And package on aur: https://aur.archlinux.org/packages/anbox-modules-dkms-aarch64

diff --git a/binder/deps.c b/binder/deps.c
index a97d546..fcde9df 100644
--- a/binder/deps.c
+++ b/binder/deps.c
@@ -8,6 +8,7 @@
 #include <linux/spinlock.h>
 #include <linux/kallsyms.h>
 #include <linux/kprobes.h>
+#include <linux/task_work.h>
 #include <linux/version.h>

 #include "deps.h"

And it works fine! But i highly recommend to reinstall kernel after it. Thanks to cracychaos!