Skip to content
This repository has been archived by the owner on Feb 13, 2024. It is now read-only.

Build error on Kernel 5.7.0 #49

Open
TheOneWithTheBraid opened this issue Apr 25, 2020 · 61 comments
Open

Build error on Kernel 5.7.0 #49

TheOneWithTheBraid opened this issue Apr 25, 2020 · 61 comments

Comments

@TheOneWithTheBraid
Copy link

The kernel modules do not seem to install on kernel 5.7.0-rc2

Asmem:

DKMS make.log for anbox-modules-ashmem-r1166.1edeb4f for kernel 5.7.0-rc2-1-git-00355-gab51cac00ef2 (x86_64)
Sat 25 Apr 2020 12:16:40 PM CEST
make -C /lib/modules/5.7.0-rc2-1-git-00355-gab51cac00ef2/build V=0 M=$PWD
make[1]: Entering directory '/usr/lib/modules/5.7.0-rc2-1-git-00355-gab51cac00ef2/build'
  AR      /var/lib/dkms/anbox-modules-ashmem/r1166.1edeb4f/build/built-in.a
  CC [M]  /var/lib/dkms/anbox-modules-ashmem/r1166.1edeb4f/build/deps.o
  CC [M]  /var/lib/dkms/anbox-modules-ashmem/r1166.1edeb4f/build/ashmem.o
  LD [M]  /var/lib/dkms/anbox-modules-ashmem/r1166.1edeb4f/build/ashmem_linux.o
  MODPOST 1 modules
ERROR: modpost: "kallsyms_lookup_name" [/var/lib/dkms/anbox-modules-ashmem/r1166.1edeb4f/build/ashmem_linux.ko] undefined!
make[2]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
make[1]: *** [Makefile:1635: modules] Error 2
make[1]: Leaving directory '/usr/lib/modules/5.7.0-rc2-1-git-00355-gab51cac00ef2/build'
make: *** [Makefile:12: all] Error 2

Binder:

DKMS make.log for anbox-modules-binder-r1166.1edeb4f for kernel 5.7.0-rc2-1-git-00355-gab51cac00ef2 (x86_64)
Sat 25 Apr 2020 12:16:36 PM CEST
make -C /lib/modules/5.7.0-rc2-1-git-00355-gab51cac00ef2/build V=0 M=$PWD
make[1]: Entering directory '/usr/lib/modules/5.7.0-rc2-1-git-00355-gab51cac00ef2/build'
  AR      /var/lib/dkms/anbox-modules-binder/r1166.1edeb4f/build/built-in.a
  CC [M]  /var/lib/dkms/anbox-modules-binder/r1166.1edeb4f/build/deps.o
  CC [M]  /var/lib/dkms/anbox-modules-binder/r1166.1edeb4f/build/binder.o
  LD [M]  /var/lib/dkms/anbox-modules-binder/r1166.1edeb4f/build/binder_linux.o
  MODPOST 1 modules
ERROR: modpost: "kallsyms_lookup_name" [/var/lib/dkms/anbox-modules-binder/r1166.1edeb4f/build/binder_linux.ko] undefined!
make[2]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
make[1]: *** [Makefile:1635: modules] Error 2
make[1]: Leaving directory '/usr/lib/modules/5.7.0-rc2-1-git-00355-gab51cac00ef2/build'
make: *** [Makefile:8: all] Error 2

Any thoughts on?

@TuxThePenguin0
Copy link

I had a quick look and this seems to be the commit that broke it for security reasons
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0bd476e6c67190b5eb7b6e105c8db8ff61103281
I guess that means the temporary solution would be to either reverse that commit in your kernel or go back to 5.6

@thanasxda
Copy link

I had a quick look and this seems to be the commit that broke it for security reasons
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0bd476e6c67190b5eb7b6e105c8db8ff61103281
I guess that means the temporary solution would be to either reverse that commit in your kernel or go back to 5.6

ill try reverting this commit and retrying on my fork of rc git thx for the info

@afandimsr
Copy link

I have the same problem, I am using a kernel system 5.3.0 on ubuntu bionic 18.04 LTS, this problem makes me unable to run anbox because ashmem and binder errors are built, can you help me?

@ghost
Copy link

ghost commented Jun 14, 2020

@ZeroLinux
The problem you described in https://bbs.archlinux.org/viewtopic.php?id=256552 is probably related to this issue.

@TuxThePenguin0
Copy link

It seems like there have been a number of changes lately that are causing issues for the Anbox modules, not just this one
For now I'd try using Linux 5.7.0 with the reverted patch, using Linux 5.6 or using some other LTS kernel

@ghost
Copy link

ghost commented Jun 14, 2020

@TuxThePenguin0

Have you tried using the built-in "modules" in 5.7?

In other words, rebuild kernel with (and don't forget to uninstall any Anbox modules (DKMS) package afterwards):

CONFIG_ASHMEM=y
CONFIG_ANDROID=y
CONFIG_ANDROID_BINDER_IPC=y
CONFIG_ANDROID_BINDERFS=y
CONFIG_ANDROID_BINDER_DEVICES="binder,hwbinder,vndbinder"

Note: In the above method, the "modules" are compiled in (=y) and cannot be compiled as loadable modules (=m).

P.S. I am still on 5.6 because I encounter i915 GPU HANG bug in 5.7.

@TuxThePenguin0
Copy link

@ipaucek4680

No I haven't tried building a kernel with the modules built in, I'm not sure where to find the patches needed to include them.

@ghost
Copy link

ghost commented Jun 14, 2020

@TuxThePenguin0

I mean, the upstream kernel (including 5.7) already has "ashmem" and "binder", so no patch is needed.

Have a look at the kernel source code and you will understand:
https://github.com/torvalds/linux/tree/master/drivers/android
https://github.com/torvalds/linux/tree/master/drivers/staging/android

If you have ever compiled the kernel in the past, you probably have to run make menuconfig and you will be able to select the entries and choose what things should be included in the kernel.

@TuxThePenguin0
Copy link

So I compiled the kernel with those added config options and anbox now works perfectly on 5.7.2.
Thanks :)

@jedi2light
Copy link

jedi2light commented Jun 15, 2020

Hi there!
I already recompiled my kernel with config options mentioned above.
Now, how can I achieve working anbox?
anbox session-manager tells that [session_manager.cpp:136@operator()] Failed to start as either binder or ashmem kernel drivers are not loaded.
I follow these instructions: https://wiki.archlinux.org/index.php/Anbox
P.S. zgrep -E 'ANDROID|ASHMEM' /proc/config.gz tells:

CONFIG_ASHMEM=y
CONFIG_ANDROID=y
CONFIG_ANDROID_BINDER_IPC=y
CONFIG_ANDROID_BINDERFS=y
CONFIG_ANDROID_BINDER_DEVICES="binder,hwbinder,vndbinder"
# CONFIG_ANDROID_BINDER_IPC_SELFTEST is not set

uname -r: 5.7.2-arch1-1

@ghost
Copy link

ghost commented Jun 16, 2020

@jedi2light
Do you still have any Anbox module package (e.g. anbox-modules-dkms-git) installed? Don't forget to uninstall it if you are already running a kernel with those added config options.

@jedi2light
Copy link

Well, I guess no...
$ pacman -Qs anbox
local/anbox-git 1:r1213.c898810-1
    Running Android in a container
local/anbox-image-gapps 2018.07.19-15
    Android image for running in Anbox, with OpenGApps and Houdini
$ pacman -Qs dmks
$ 

@jedi2light
Copy link

jedi2light commented Jun 16, 2020

Oh, i found /var/lib/dkms with anbox-modules. Removed it.

@jedi2light
Copy link

And, unfortunately, it does not work :(
The same error

@ghost
Copy link

ghost commented Jun 17, 2020

@jedi2light
Please try removing all leftover files, e.g. /usr/lib/modules-load.d/anbox.conf and the compiled ashmem and binder .ko files.

@TuxThePenguin0
Copy link

On my system I needed to add an fstab entry to mount the binderfs filesystem to /dev/binder before anbox would start.
Maybe the anbox out of tree modules automatically do that while the in tree ones don't?

@TuxThePenguin0
Copy link

Also run dkms status and make sure that dkms doesn't still have the modules installed. If it does then they should be removable with the dkms utility.

@ghost
Copy link

ghost commented Jun 17, 2020

On my system I needed to add an fstab entry to mount the binderfs filesystem to /dev/binder before anbox would start.
Maybe the anbox out of tree modules automatically do that while the in tree ones don't?

I used in-tree modules before (on Arch Linux) and an fstab entry was not needed.
I can't test on 5.7 kernel because the GPU hang bug causes KDE to fail to load.

@jedi2light
Copy link

jedi2light commented Jun 17, 2020

@TuxThePenguin0 @ipaucek4680

$ ls /usr/lib/modules-load.d/anbox.conf
ls: невозможно получить доступ к '/usr/lib/modules-load.d/anbox.conf': No such file or directory
$ find /usr/lib/modules -name *ashmem*
/usr/lib/modules/5.7.2-arch1-1/build/include/config/ashmem.h
$ find /usr/lib/modules -name *binder*
/usr/lib/modules/5.7.2-arch1-1/build/Documentation/admin-guide/binderfs.rst
/usr/lib/modules/5.7.2-arch1-1/build/Documentation/admin-guide/binderfs.html
/usr/lib/modules/5.7.2-arch1-1/build/Documentation/_sources/admin-guide/binderfs.rst.txt
/usr/lib/modules/5.7.2-arch1-1/build/include/uapi/linux/android/binderfs.h
/usr/lib/modules/5.7.2-arch1-1/build/include/uapi/linux/android/binder.h
/usr/lib/modules/5.7.2-arch1-1/build/include/config/android/binder
/usr/lib/modules/5.7.2-arch1-1/build/include/config/android/binderfs.h
$ dkms status

@jedi2light
Copy link

On my system I needed to add an fstab entry to mount the binderfs filesystem to /dev/binder before anbox would start.
Maybe the anbox out of tree modules automatically do that while the in tree ones don't?

Can you share your fstab line?

@jedi2light
Copy link

Oh, i found the solution at kernel doc

$ sudo mkdir /dev/binderfs
$ sudo mount -t binder binder /dev/binderfs
$ anbox session-manager

And finally its alive!

@ghost
Copy link

ghost commented Jun 21, 2020

So what exactly I have to do to get anbox running on arch with kernel 5.7.4?

@jedi2light
Copy link

So what exactly I have to do to get anbox running on arch with kernel 5.7.4?

Not sure if this works on 5.7.4, but on 5.7.2 you should go through next steps:

  1. Using your AUR helper install anbox-git, anbox-image (or anbox-image-gapps if you want to include Google's Apps and houdini);
  2. Buid linux kernel wiith
CONFIG_ASHMEM=y
CONFIG_ANDROID=y
CONFIG_ANDROID_BINDER_IPC=y
CONFIG_ANDROID_BINDERFS=y
CONFIG_ANDROID_BINDER_DEVICES="binder,hwbinder,vndbinder"

You can use https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux to build your own kernel with modified config
4. Reboot to new kernel
5. sudo mkdir /dev/binderfs
6. sudo mount -t binder binder /dev/binderfs
7. Follow https://wiki.archlinux.org/index.php/Anbox

@jedi2light
Copy link

Also fixed Arch Linux wiki page for Anbox: https://wiki.archlinux.org/index.php/Anbox

@xNinjaKittyx
Copy link

Is there a way I can verify that the linux kernel correctly built with the config values? (I'm still a newbie when it comes to building the kernel).

I've tried this several times with 5.7.4 and 5.7.6-2 (using Manjaro's gitlab repository), and I'm not able to mount using binder.

I modified both config and config.x86_64 in manjaro's repository.

mount: /dev/binderfs: unknown filesystem type 'binder'.
uname -a
Linux manjaroxd 5.7.6-2-MANJARO #1 SMP PREEMPT Thu Jun 25 17:12:28 PDT 2020 x86_64 GNU/Linux

@ghost
Copy link

ghost commented Sep 11, 2020

and does uname -a showed the kernel name which you specified in pkgbuild?

I didn't specify any special name, I just replaced the kernel outright, so technically, yes.

@ghost
Copy link

ghost commented Sep 11, 2020

Okay, after doing some more research, I needed to enable the menuconfig option in the PKGBUILD for Liquorix, then set the correct flags there, and I even reached out to the developer of the kernel, and he's set to have it pre-packaged into the kernel on next release, so good stuff all around.

@clebercasali
Copy link

clebercasali commented Oct 30, 2020

https://techpatterns.com/forums/about2842.html
I'm using the latest Liquorix kernel, and still can't start Anbox.
Any news on that?

@nonetrix
Copy link

nonetrix commented Nov 9, 2020

Is this still a issue I don't really want to downgrade since the newest kernel adds new compresson type that sped up my boot times

@lss4
Copy link

lss4 commented Nov 9, 2020

Is this still a issue I don't really want to downgrade since the newest kernel adds new compresson type that sped up my boot times

The modules are not needed anymore with 5.7 and later kernels. You just need to specify the build parameters in your kernel config.

By the way, latest Manjaro kernel PKGBUILDs already included anbox-related parameters so you should be able to use it out-of-box on those kernels.

EDIT: Not sure if there's a good way to ask dkms to build the modules only on kernels 5.6 or earlier, as those "bad status" dkms errors/warnings can be a bit annoying.

@X-dark
Copy link

X-dark commented Nov 9, 2020

How can this be an improvement, if the result is to have to rebuild the whole kernel instead of just modules? Or maybe I am missing something?

@SoulEst
Copy link

SoulEst commented Nov 9, 2020

How can this be an improvement, if the result is to have to rebuild the whole kernel instead of just modules? Or maybe I am missing something?

The other option is to use the linux-zen kernel which is already compiled with the correct modules.

@nonetrix
Copy link

How can this be an improvement, if the result is to have to rebuild the whole kernel instead of just modules? Or maybe I am missing something?

how can I enable them? I've compiled the kernel a few times

@lss4
Copy link

lss4 commented Nov 25, 2020

How can this be an improvement, if the result is to have to rebuild the whole kernel instead of just modules? Or maybe I am missing something?

how can I enable them? I've compiled the kernel a few times

This is from Manjaro's official kernel PKGBUILD repo. This part contains the necessary build parameters for anbox-related modules and you can just append these lines to your existing config.

@angelsl
Copy link

angelsl commented Dec 2, 2020

@X-dark

How can this be an improvement, if the result is to have to rebuild the whole kernel instead of just modules?

If you read the commit message of the commit that unexported kallsyms_lookup_name:

kallsyms_lookup_name() and kallsyms_on_each_symbol() are exported to modules despite having no in-tree users and being wide open to abuse by out-of-tree modules that can use them as a method to invoke arbitrary non-exported kernel functions.

This is basically exactly what Anbox is doing.

It's a security improvement for the Linux kernel. Unfortunately it makes it very inconvenient for Anbox.

@DEVoytas
Copy link

Has anyone considered this workaround: lttng/lttng-modules@a657654 ?

TL;DR:
[...] continues working for my end users on kernels 5.7 onwards [...]
It basically uses kprobes to lookup the kallsyms_lookup_name symbol, and
continues using kallsyms_lookup_name as before.

@brightersun99
Copy link

What a bunch of incompetent monkeys.

Am I supposed to go install kernel 2.2 to use anbox?

fuck off

@TuxThePenguin0
Copy link

No you're supposed to either help maintain the project, find a workaround or build a kernel with the needed features built in anyway.
You do realise this project hasn't been properly maintained in ages right?

@lss4
Copy link

lss4 commented Dec 18, 2020

The modules are now upstream and can be enabled from kernel configuration since 5.7.0 and this is no longer needed. Period.

How can this be an improvement, if the result is to have to rebuild the whole kernel instead of just modules? Or maybe I am missing something?

If you read the commit message of the commit that unexported kallsyms_lookup_name:

kallsyms_lookup_name() and kallsyms_on_each_symbol() are exported to modules despite having no in-tree users and being wide open to abuse by out-of-tree modules that can use them as a method to invoke arbitrary non-exported kernel functions.

This is basically exactly what Anbox is doing.

It's a security improvement for the Linux kernel. Unfortunately it makes it very inconvenient for Anbox.

It seems the topic is starting to derail into the concerns that people now have to make custom kernel build themselves to enable the modules, as the official kernel packages from their respective Linux distros may not have this enabled by default.

Building a kernel can be difficult for some users, and may take very long if the user's CPU is weak. It may also disrupt regular package update routines as now one needs to manually build and install the kernel packages themselves instead of installing from official sources.

Prior to the changes in 5.7.0, users can just update their systems and dkms will rebuild the modules afterwards, with no changes in usual update routines. Now this is no longer possible, if their distro does not ship kernels with this option enabled by default. It would be up to the kernel maintainers of the respective distros to decide whether or not they provide kernel variants with this enabled.

@choff
Copy link

choff commented Mar 8, 2021

Hello all,

for all those who really need working kernel modules for anbox, you can try my dirty fixes in https://github.com/choff/anbox-modules that make ashmem and binder work again with later kernels. The most important change was to use KProbes to look up the address of kallsysms_lookup_name(), to be able to continue to use this function as before. Yes, I know it is dirty - hopefully it nevertheless helps one or the other person out there. The better solution is surely to contact the kernel maintainer of your Linux distro to enable ashmem and binder support in the kernel. So, this is just a solution if nothing else works.

I have also opened a pull request (#76 ) for this - let's see if it will be integrated...

Best regards,

Christian

@SoulInfernoDE
Copy link

SoulInfernoDE commented Mar 13, 2021

Oh, i found the solution at kernel doc

$ sudo mkdir /dev/binderfs
$ sudo mount -t binder binder /dev/binderfs
$ anbox session-manager

And finally its alive!

At my side i needed to do:

$ sudo mkdir /dev/binder
$ sudo mount -t binder binder /dev/binder
$ anbox system-info

$ anbox system-info
then shows

ASHMEM=true
BINDER=true

if i use /dev/binderfs instead anbox doesn't seem to recognize binder then.

but Anbox shows this error now while trying to start:

$ anbox session-manager
[ 2021-03-13 17:48:33] [Renderer.cpp:128@initialize] Failed to select EGL configuration
Stack trace (most recent call last) in thread 9026:
#7    Object "[0xffffffffffffffff]", at 0xffffffffffffffff, in 
#6    Object "/snap/anbox/209/lib/x86_64-linux-gnu/libc.so.6", at 0x7f9b7737c292, in clone
#5    Object "/snap/anbox/209/lib/x86_64-linux-gnu/libpthread.so.0", at 0x7f9b776ec608, in 
#4    Object "/snap/anbox/209/usr/bin/anbox", at 0x5641df889e64, in emugl::Thread::thread_main(void*)
#3    Object "/snap/anbox/209/usr/bin/anbox", at 0x5641df7962c8, in RenderThread::main()
#2    Object "/snap/anbox/209/usr/bin/anbox", at 0x5641df884bb0, in renderControl_decoder_context_t::decode(void*, unsigned long, IOStream*)
#1    Object "/snap/anbox/209/usr/bin/anbox", at 0x5641df8044d2, in 
#0    Object "/snap/anbox/209/usr/bin/anbox", at 0x5641df807399, in RendererConfigList::getPackInfo(int*, int*) const
Segmentation fault (Address not mapped to object [(nil)])
Speicherzugriffsfehler (Speicherabzug geschrieben)

br
SI

@choff
Copy link

choff commented Mar 15, 2021

Hello @SoulInfernoDE ,

thanks for sharing your solution, which also helped me to get past the issue that Anbox does not recognize Binder. Now I finally know that it is because binderfs wasn't mounted...

The Anbox issue you reported seems like an OpenGL issue ("Failed to select EGL configuration") - maybe graphics drivers for hardware acceleration need to be installed? Also the stack trace comes from the OpenGL code in Anbox. Maybe it is worth to compile Anbox from source - then you get much better stack traces - at least if libunwind is installed. These better stack traces could then be used to create a bug report against Anbox.

I finally got Anbox running yesterday evening with Binder and Ashmem support built into the kernel.

Best regards,

Christian

@sibiantony
Copy link

For all looking for a quick fix, check @choff 's comment above. #49 (comment)

  1. Either pull from his repository or apply the patches in his pull request to your locally checked out sources
  2. Build as usual
  3. If you're on secure boot, your module loader might complain. So either enroll your own mahcine owner keys or in the worst case, disable secure boot.
  4. Load the modules.
  5. Launch anbox

@SoulInfernoDE
Copy link

I just wanted to add that i needed to add a line to /etc/fstab to make /dev/binder permanent available to the system:

#50 (comment)

@0n1cOn3
Copy link

0n1cOn3 commented Oct 17, 2021

Hello all,

for all those who really need working kernel modules for anbox, you can try my dirty fixes in https://github.com/choff/anbox-modules that make ashmem and binder work again with later kernels. The most important change was to use KProbes to look up the address of kallsysms_lookup_name(), to be able to continue to use this function as before. Yes, I know it is dirty - hopefully it nevertheless helps one or the other person out there. The better solution is surely to contact the kernel maintainer of your Linux distro to enable ashmem and binder support in the kernel. So, this is just a solution if nothing else works.

I have also opened a pull request (#76 ) for this - let's see if it will be integrated...

Best regards,

Christian

Hi @choff
Thanks for your fixes in your current repo. In fact, that i cant open a issue, ill add it here cause it's based on this issue aswell.
But there's now another issue which appeared:

DKMS make.log for anbox-binder-1 for kernel 5.13.0-kaisen1-amd64 (x86_64)
Sun 17 Oct 2021 06:07:44 CEST
make -C /lib/modules/5.13.0-kaisen1-amd64/build V=0 M=$PWD
make[1]: directory "/usr/src/linux-headers-5.13.0-kaisen1-amd64" is entered
CC [M] /var/lib/dkms/anbox-binder/1/build/deps.o
CC [M] /var/lib/dkms/anbox-binder/1/build/binder.o
CC [M] /var/lib/dkms/anbox-binder/1/build/binder_alloc.o
CC [M] /var/lib/dkms/anbox-binder/1/build/binderfs.o
/var/lib/dkms/anbox-binder/1/build/binderfs.c: In function 'binderfs_rename':
/var/lib/dkms/anbox-binder/1/build/binderfs.c:367:23: Error: passing argument 1 of 'simple_rename' from an incompatible pointer type [-Werror=incompatible-pointer-types].
367 | return simple_rename(old_dir, old_dentry, new_dir, new_dentry, flags);
| ^~~~~~~
| |
| struct inode *
Contained in the file from /var/lib/dkms/anbox-binder/1/build/binderfs.c:5:
/usr/src/linux-headers-5.13.0-kaisen1-common/include/linux/fs.h:3414:26: note: expected 'struct user_namespace *' but argument is of type 'struct inode *'
3414 | external int simple_rename(struct user_namespace *, struct inode *,
| ^~~~~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/anbox-binder/1/build/binderfs.c:367:32: Error: passing argument 2 of 'simple_rename' of an incompatible pointer type [-Werror=incompatible-pointer-types]
367 | return simple_rename(old_dir, old_dentry, new_dir, new_dentry, flags);
| ^~~~~~~~~~
| |
| struct dentry *
Contained in the file from /var/lib/dkms/anbox-binder/1/build/binderfs.c:5:
/usr/src/linux-headers-5.13.0-kaisen1-common/include/linux/fs.h:3414:51: note: expected 'struct inode *' but argument is of type 'struct dentry *'
3414 | external int simple_rename(struct user_namespace *, struct inode *,
| ^~~~~~~~~~~~~~
/var/lib/dkms/anbox-binder/1/build/binderfs.c:367:44: Error: passing argument 3 of 'simple_rename' of incompatible pointer type [-Werror=incompatible-pointer-types]
367 | return simple_rename(old_dir, old_dentry, new_dir, new_dentry, flags);
| ^~~~~~~
| |
| struct inode *
Contained in the file from /var/lib/dkms/anbox-binder/1/build/binderfs.c:5:
/usr/src/linux-headers-5.13.0-kaisen1-common/include/linux/fs.h:3415:5: note: expected 'struct dentry *' but argument is of type 'struct inode *'
3415 | struct dentry *, struct inode *, struct dentry *,
| ^~~~~~~~~~~~~~~
/var/lib/dkms/anbox-binder/1/build/binderfs.c:367:53: Error: passing argument 4 of 'simple_rename' from an incompatible pointer type [-Werror=incompatible-pointer-types]
367 | return simple_rename(old_dir, old_dentry, new_dir, new_dentry, flags);
| ^~~~~~~~~~
| |
| struct dentry *
Contained in the file from /var/lib/dkms/anbox-binder/1/build/binderfs.c:5:
/usr/src/linux-headers-5.13.0-kaisen1-common/include/linux/fs.h:3415:22: note: expected 'struct inode *' but argument is of type 'struct dentry *'
3415 | struct dentry *, struct inode *, struct dentry *,
| ^~~~~~~~~~~~~~
/var/lib/dkms/anbox-binder/1/build/binderfs.c:367:9: Error: too few arguments for function 'simple_rename'.
367 | return simple_rename(old_dir, old_dentry, new_dir, new_dentry, flags);
| ^~~~~~~~~~~~~
Contained in the file from /var/lib/dkms/anbox-binder/1/build/binderfs.c:5:
/usr/src/linux-headers-5.13.0-kaisen1-common/include/linux/fs.h:3414:12: note: declared here
3414 | external int simple_rename(struct user_namespace *, struct inode ,
| ^~~~~~~~~~~~~
/var/lib/dkms/anbox-binder/1/build/binderfs.c: At top level:
/var/lib/dkms/anbox-binder/1/build/binderfs.c:467:12: Error: Initialization of 'int (
)(struct user_namespace *, struct inode *, struct dentry *, struct inode *, struct dentry , unsigned int)' of incompatible pointer type 'int ()(struct inode *, struct dentry *, struct inode *, struct dentry *, unsigned int)' [-Werror=incompatible-pointer-types.]
467 | .rename = binderfs_rename,
| ^~~~~~~~~~~~~~~
/var/lib/dkms/anbox-binder/1/build/binderfs.c:467:12: Note: (on initialisation for 'binderfs_dir_inode_operations.rename')
/var/lib/dkms/anbox-binder/1/build/binderfs.c: In function 'binderfs_rename':
/var/lib/dkms/anbox-binder/1/build/binderfs.c:368:1: error: control reaches end of non-void function [-Werror=return-type]
368 | }
| ^
cc1: some warnings are treated as errors
make[3]: *** [/usr/src/linux-headers-5.13.0-kaisen1-common/scripts/Makefile.build:278: /var/lib/dkms/anbox-b

@choff
Copy link

choff commented Nov 1, 2021

Hello @0n1cOn3 ,

yes, I was also made aware of this issue by others. Please try the latest version of anbox-modules; it contains a (so far untested) fix for this issue. I would be happy if you could give it a try and give me feedback if it works or not.

Best regards,

Christian

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests