Request Fedora support for Anbox: https://github.com/anbox/anbox needs dkms packages for ashmem and binder kernel module to work on fedora. Corresponding anbox issue: https://github.com/anbox/anbox/issues/85
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
It'd not happen, since Fedora doesn't allow third party kernel modules.
(In reply to Hedayat Vatankhah from comment #2) > It'd not happen, since Fedora doesn't allow third party kernel modules. ashmem and binder are in the official kernel sources. Maybe Fedora could have a kernel-modules-experimental package?
Oops, sorry, I thought that they are not in the official kernel.
Oops, sorry, I thought that they are not in the mainline kernel.
Yes the drivers are in the mainline tree but I'm not excited about turning them on. ashmem is still very much in staging and the status of its replacement is kind of nebulous. While binder has moved out of staging, it's still tightly bound to libbinder in userspace. Enabling both of these in Fedora also increases the potential attack surface for exploits. Anbox support should be going through Fesco for approval and have an owner to drive it, similar to the virtualbox drivers. This is not something the Fedora kernel maintainers can take up at the moment. I'm going to close this bug for now but if someone wants to drive this per https://fedoraproject.org/wiki/Changes/Policy this bug can be reopened.
Literally every bit of an OS makes it less secure. By this reasoning, why not remove the ability to do iptables -F, chmod 777 or sudo rm -rf /. Unlike anbox, Those are all present in the default install. Dkms makes anbox opt-in. This is consistent with Unix philosophy to provide the mechanism, not the policy. > This is not something the Fedora kernel maintainers can take up at the moment. I'm going to close this bug for now but if someone wants to drive this per https://fedoraproject.org/wiki/Changes/Policy this bug can be reopened. I thought the whole concept of the Fedora <-> RHEL divide was to be a staging ground for the new stuff. Please reopen it, if driving it means I have to create a wiki page for it I'll do it.
I'm with Eric. So I think time to close it not came yet.
(In reply to eric from comment #7) > Literally every bit of an OS makes it less secure. By this reasoning, why > not remove the ability to do iptables -F, chmod 777 or sudo rm -rf /. Unlike > anbox, Those are all present in the default install. Dkms makes anbox > opt-in. This is consistent with Unix philosophy to provide the mechanism, > not the policy. Fedora doesn't do DKMS in the core distro, if you want that functionality it goes into rpmfusion. And something like iptables is not the same as opening the OS up to android malware. > > This is not something the Fedora kernel maintainers can take up at the moment. I'm going to close this bug for now but if someone wants to drive this per https://fedoraproject.org/wiki/Changes/Policy this bug can be reopened. > > I thought the whole concept of the Fedora <-> RHEL divide was to be a > staging ground for the new stuff. Please reopen it, if driving it means I > have to create a wiki page for it I'll do it. It is, it's also nothing to do with RHEL. There's a lot of things done in Fedora but ultimately, as Laura mentioned, if you wish to do it yourself as an official change you can follow the policy linked and have it go through the Engineering Steering Committee (FESCo) for review and then have someone implement it. A feature such as Anbox isn't as simple as enabling a few kernel modules and your done, it requires userspace and maintenance and contacts to deal with security CVEs etc
> Fedora doesn't do DKMS in the core distro, if you want that functionality it > goes into rpmfusion. The two modules we talking about are included in Kernel not separated ones !!! > A feature such as Anbox isn't as simple as enabling a few kernel modules and > your done, it requires userspace and maintenance and contacts to deal with > security CVEs etc It's not new package to do this !!!
It does not matter. If Fedora does not want to include them, you should ask rpmfusion.
Greg KH had this to say about binder today: "To be fair, lots of people, including myself, have always said, "never run binder on a system that is not a 'real' Android system" for a variety of good reasons, including security issues. "Now around the 4.10 or so kernel release, most of those issues were resolved, and with 4.14, all of those have been taken care of (that I know of), so this should be allowed." So at least for binder the obvious security problems that would have stopped it from being included have been fixed.
(In reply to Peter Robinson from comment #9) > (In reply to eric from comment #7) > > Literally every bit of an OS makes it less secure. By this reasoning, why > > not remove the ability to do iptables -F, chmod 777 or sudo rm -rf /. Unlike > > anbox, Those are all present in the default install. Dkms makes anbox > > opt-in. This is consistent with Unix philosophy to provide the mechanism, > > not the policy. > > Fedora doesn't do DKMS in the core distro, if you want that functionality it > goes into rpmfusion. > > And something like iptables is not the same as opening the OS up to android > malware. the original request said dkms but imho it was an accident. it should have to compiled as a kernel module for fedora (like all other kernel modules). about the userspace anbox is s totally different issue and probably a separate bugzilla. but if the kernel module already included external or corp repos can add support for anbox.
It's clear there is a lot of interest in Anbox on Fedora. As has been stated, just enabling the kernel modules isn't enough though as there are userspace components as well. This needs to go through the change process https://fedoraproject.org/wiki/Changes/Policy so everything can be reviewed and provide the best experience for Fedora. To the binder point, I've been following binder for years. I'm thrilled with the progress it has made to get cleaned up and usable outside of Android. This is the bare minimum of usability though and my completely biased opinion is that enabling it still needs careful review and someone to advocate for it. The change process is designed to provide a path for options like this.
Someone else might want to create the wiki page. I couldn't get past the captcha on signup page.
(In reply to Laura Abbott from comment #14) > It's clear there is a lot of interest in Anbox on Fedora. As has been > stated, just enabling the kernel modules isn't enough though as there are > userspace components as well. This needs to go through the change process > https://fedoraproject.org/wiki/Changes/Policy so everything can be reviewed > and provide the best experience for Fedora. > > To the binder point, I've been following binder for years. I'm thrilled with > the progress it has made to get cleaned up and usable outside of Android. > This is the bare minimum of usability though and my completely biased > opinion is that enabling it still needs careful review and someone to > advocate for it. The change process is designed to provide a path for > options like this. Please, people, participate in moving this process forward, if you would like to see Anbox on Fedora! @Neal, so do you actually know what the story with some folks apparently able to make it work with snapd-2.30, but not early versions, was? > See Also: https://bugzilla.redhat.com/show_bug.cgi?id=1546896 (Indeed.)
(In reply to rcmin17 from comment #16) > (In reply to Laura Abbott from comment #14) > > It's clear there is a lot of interest in Anbox on Fedora. As has been > > stated, just enabling the kernel modules isn't enough though as there are > > userspace components as well. This needs to go through the change process > > https://fedoraproject.org/wiki/Changes/Policy so everything can be reviewed > > and provide the best experience for Fedora. > > > > To the binder point, I've been following binder for years. I'm thrilled with > > the progress it has made to get cleaned up and usable outside of Android. > > This is the bare minimum of usability though and my completely biased > > opinion is that enabling it still needs careful review and someone to > > advocate for it. The change process is designed to provide a path for > > options like this. > > Please, people, participate in moving this process forward, if you would > like to see Anbox on Fedora! > > @Neal, so do you actually know what the story with some folks apparently > able to make it work with snapd-2.30, but not early versions, was? > > > See Also: https://bugzilla.redhat.com/show_bug.cgi?id=1546896 > > (Indeed.) The Anbox installer script might be doing something along the lines of DKMS, but as far as I knew, the scripts are Ubuntu specific, so I would expect it to not work...?
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs. Fedora 27 has now been rebased to 4.17.7-100.fc27. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28. If you experience different issues, please open a new bug report for those.
Any progress here?
With the introduction of binderfs in Linux 5.0, it looks like it's in a good shape for enablement. I don't know if any progress was made on ashmem, though. My understanding is that both are required for this.
Yes, there has been good progress. I still want this to go through as a feature change for Fedora.
(In reply to Laura Abbott from comment #21) > Yes, there has been good progress. I still want this to go through as a > feature change for Fedora. Is there any further updates on this?
> Is there any further updates on this? None yet, it looks like.
Looks like, the Fedora folks weren't very thrilled to bring these modules to the fedora due to these components being in early stages. But I hope things have changed recently. I would like to help in any way I can, so I will first start reading about the process. But if there's anyone in this thread who can point me in the right direction, that would be of great help to me. Thanks.
I tried Re-CCing and needinfo labbott who reported not wanting to enable aformentionned kernel modules in their current state as of 2019, but her account is disabled according to bugzilla error message. Maybe those modules situation is better now? Who can answer to that? I can not "Needinfo" current assignee Kernel-maint either, as I also receive the message "account is disabled".
> Maybe those modules situation is better now? The situation is not currently any better the last I looked a few months ago.
AFAICT Debian has both ashmem and binder enabled in their kernel, for the later they apply a patch to allow building it as a loadable module. I suppose they consider the modules in good enough shape to include in a stable distro?
(In reply to Filippe LeMarchand from comment #27) > AFAICT Debian has both ashmem and binder enabled in their kernel, for the > later they apply a patch to allow building it as a loadable module. I > suppose they consider the modules in good enough shape to include in a > stable distro? You would have to ask Debian. For Fedora this needs someone to do the work, maintain it in the long term, deal with bugs/issues/etc. No one has stepped up to do that work.
(In reply to Filippe LeMarchand from comment #27) > AFAICT Debian has both ashmem and binder enabled in their kernel, for the > later they apply a patch to allow building it as a loadable module. I > suppose they consider the modules in good enough shape to include in a > stable distro? The patch for building them as loadable modules needs to be upstreamed too.
here's a link to the patch https://salsa.debian.org/kernel-team/linux/-/raw/master/debian/patches/debian/android-enable-building-ashmem-and-binder-as-modules.patch
Is Waydroid in the same boat as anbox? Would be realy awesome to see Fedora support this. https://www.xda-developers.com/waydroid-android-apps-on-linux/
From a kernel standpoint, if someone gets the patch to build binder and binderfs as modules upstream, I don't mind turning them on. Until that happens, I am not particularly interested in carrying them as built-in. And no, they can't be subpackages, or handled separately since they do require built-in. Without that patch, they would require a separate kernel build. Ashmem has a similar problem, it needs the patch to build as a module upstreamed, and additionally it needs to move out of staging. There was discussion at Plumbers in 2018 about how to get ashmem out of staging, but it seems no one cared enough to follow up.
(In reply to Justin M. Forbes from comment #32) > From a kernel standpoint, if someone gets the patch to build binder and > binderfs as modules upstream, I don't mind turning them on. Until that > happens, I am not particularly interested in carrying them as built-in. And > no, they can't be subpackages, or handled separately since they do require > built-in. Without that patch, they would require a separate kernel build. > Ashmem has a similar problem, it needs the patch to build as a module > upstreamed, and additionally it needs to move out of staging. There was > discussion at Plumbers in 2018 about how to get ashmem out of staging, but > it seems no one cared enough to follow up. I tried to write to Debian in July on the bug entry related to these patches, to ask for upstreaming them, but got bounced (Your message wasn't delivered to 901492.org because the address couldn't be found, or is unable to receive mail. The response from the remote server was: 550 Unknown or archived bug). Does anyone know to contact, and who to contact at Debian to ask this again? My bounced email to Debian : ---------- Forwarded message --------- From: sheepdestroyer <sheepdestroyer> Date: Sun, Jul 11, 2021 at 6:15 PM Subject: Upstreaming the patch to make binder and ashmem buildable as modules To: <901492.org> Hello, Could you consider upstreaming the patch to make binder and ashmem buildable as modules [0] ? This seems to be one of the blockers for Fedora to enable Anbox [1] [0] https://salsa.debian.org/kernel-team/linux/-/raw/master/debian/patches/debian/android-enable-building-ashmem-and-binder-as-modules.patch [1] https://bugzilla.redhat.com/show_bug.cgi?id=1455411 Best regards
So I tried the Debian patch and it doesn't work, so I've been rewriting it as a patch series that is potentially upstreamable: https://github.com/Conan-Kudo/linux/commits/5.14-rc4-binder-and-ashmem-modules Unfortunately, it doesn't yet work (but at least I can make ko files, even if there's tons of unresolved symbols...).
So now there's Waydroid, a fork of Anbox that's more performant and leverages Wayland: https://waydro.id/ Also, today, I was in LPC in the Android MC asking about this, and Greg Kroah-Hartman recommended to me that we just ship binder as a built-in so that binderfs is available. He assures that there are no issues about shipping it on conventional Linux systems as a built-in and is namespace/container-safe. As for ashmem, the Greg and the Android team folks said we shouldn't need it unless we intend to support old Android apps through the Google Play Store, as ashmem is long-deprecated in Android. As I don't think Fedora Mobile will go through Google Play Store certification, I think we could get away without having it. If you think it's fine, I can work with the Fedora KDE and Fedora Mobile SIGs to come up with a plan and a Change proposal for enabling this and getting Waydroid into Fedora.
Woah! That'd be awesome.
@Neal Gompa yes, getting Waydroid into Fedora would be very nice. Thank you.
I have a customer looking to transition to running android apps on x86_64 with an alternate linux distro. It's not entirely clear how this is going to be accomplished but I suspect its either a VM or thin shim layer similar to Anbox. The APK they want to run is here ... https://www.civtak.org/ ... with the APK file here ... https://drive.google.com/drive/folders/1nf97w1N870gm4PYPEEwO78OLPt8J9Ty7 How can I determine if this app requires ashmem, per the above discussion on only including binderfs in the OS?
(In reply to Rich Lucente from comment #38) > I have a customer looking to transition to running android apps on x86_64 > with an alternate linux distro. It's not entirely clear how this is going to > be accomplished but I suspect its either a VM or thin shim layer similar to > Anbox. > > The APK they want to run is here ... https://www.civtak.org/ ... with the > APK file here ... > https://drive.google.com/drive/folders/1nf97w1N870gm4PYPEEwO78OLPt8J9Ty7 > > How can I determine if this app requires ashmem, per the above discussion on > only including binderfs in the OS? So, it's not *that* simple: Android applications *typically* get access through the libcutils API, and that could be patched to use memfd (probably what we want) or compiled to use the stub tmp-based implementation (*might* work?). If it opens /dev/ashmem directly (which some older apps do), it'll fail when you try to use the app if ashmem isn't available. My understanding is that Android *itself* has moved away from it, and aside from the pinning API, all of the functions can be reimplemented using memfds. Reference: * Slides on plan to get rid of ashmem from LPC 2018: https://www.linuxplumbersconf.org/event/2/contributions/227/attachments/51/58/08._ashmem_-_getting_it_out_of_staging.pdf * ashmem-backed ashmem API: https://android.googlesource.com/platform/system/core/+/refs/heads/master/libcutils/ashmem-dev.cpp * tmp-based ashmem API: https://android.googlesource.com/platform/system/core/+/refs/heads/master/libcutils/ashmem-host.cpp
(In reply to Neal Gompa from comment #35) > So now there's Waydroid, a fork of Anbox that's more performant and > leverages Wayland: https://waydro.id/ > > Also, today, I was in LPC in the Android MC asking about this, and Greg > Kroah-Hartman recommended to me that we just ship binder as a built-in so > that binderfs is available. He assures that there are no issues about > shipping it on conventional Linux systems as a built-in and is > namespace/container-safe. In order to avoid kernel recompiling and replacement, I wonder whether the binderfs (and ashmem) are straightforward to implement using CUSE (character device in userspace). > As for ashmem, the Greg and the Android team folks said we shouldn't need it > unless we intend to support old Android apps through the Google Play Store, > as ashmem is long-deprecated in Android. As I don't think Fedora Mobile will > go through Google Play Store certification, I think we could get away > without having it. Ashmem as CUSE would drop the need for ashmem maintenance within the kernel.
(In reply to Neal Gompa from comment #39) > > How can I determine if this app requires ashmem, per the above discussion on > > only including binderfs in the OS? > > So, it's not *that* simple: Android applications *typically* get access > through the libcutils API, and that could be patched to use memfd (probably > what we want) or compiled to use the stub tmp-based implementation (*might* > work?). If it opens /dev/ashmem directly (which some older apps do), it'll > fail when you try to use the app if ashmem isn't available. I reached out to the ATAK developers on the development channel of their discord server (https://discord.gg/wNHJ9YZ). This was their reply ... > simple test would be run atak and cat /proc/pid/maps and see if there are any ashmem file descriptors open or grep -rn ashmem <your_atak_checkout> > > user@user-VirtualBox:~/code/atak-4.4.0/AndroidTacticalAssaultKit-CIV/atak-civ$ grep -rni ashmem . > user@user-VirtualBox:~/code/atak-4.4.0/AndroidTacticalAssaultKit-CIV/atak-civ$ > > looks like no on the latter > > starlte:/ # cat /proc/`pgrep -o atak`/maps | grep -i ashmem > 767d211000-767d231000 rw-s 00000000 00:01 56115 /dev/ashmem/shared_memory/CF7E72E19B07127D1788E9E628881011_4909_4909 (deleted) > 76b57a8000-76b57b2000 rw-s 00000000 00:01 40479 /dev/ashmem/shared_memory/F3757D2B31C4F77750636CDFD5B14D43_4909_6378 (deleted) > 770fcef000-770fcf3000 r--p 00000000 103:02 3829 /system/lib64/ashmemd_aidl_interface-cpp.so > 770fcf3000-770fcf4000 --xp 00004000 103:02 3829 /system/lib64/ashmemd_aidl_interface-cpp.so > 770fcf4000-770fcf5000 rw-p 00005000 103:02 3829 /system/lib64/ashmemd_aidl_interface-cpp.so > 770fcf5000-770fcf7000 r--p 00006000 103:02 3829 /system/lib64/ashmemd_aidl_interface-cpp.so > 770fd17000-770fd18000 r--p 00000000 103:02 4009 /system/lib64/libashmemd_client.so > 770fd18000-770fd19000 --xp 00001000 103:02 4009 /system/lib64/libashmemd_client.so > 770fd19000-770fd1a000 rw-p 00002000 103:02 4009 /system/lib64/libashmemd_client.so > 770fd1a000-770fd1b000 r--p 00003000 103:02 4009 /system/lib64/libashmemd_client.so > 77a4973000-77a4974000 r--s 00000000 00:01 30908 /dev/ashmem/5027b323-2b64-4982-b8f0-0108973614ee_749_749 (deleted) > 77a4a2a000-77a4a2b000 rw-s 00000000 00:01 45854 /dev/ashmem/GFXStats-4909_749_3470 (deleted) > 77a52b6000-77a52b7000 r--s 00000000 00:01 30908 /dev/ashmem/5027b323-2b64-4982-b8f0-0108973614ee_749_749 (deleted) > 77a56d5000-77a56d6000 r--s 00000000 00:01 30908 /dev/ashmem/5027b323-2b64-4982-b8f0-0108973614ee_749_749 (deleted) > 77a95c0000-77a95c1000 r--s 00000000 00:01 30908 /dev/ashmem/5027b323-2b64-4982-b8f0-0108973614ee_749_749 (deleted) > > looks like yes on the first > > ashmem is part of gnu/linux you should be able to just toggle the CONFIG_ in your kernel and recompile > maybe even have it as a module with like sudo modprobe ashmem_linux So no direct reference to ashmem in the source code but it's still being used by the application. Does this mean the memfd patch would remove the dependency?
(In reply to Rich Lucente from comment #41) > > So no direct reference to ashmem in the source code but it's still being > used by the application. Does this mean the memfd patch would remove the > dependency? Yes. If libcutils is patched in the Fedora Android userspace build, then we'd be set for this application.
A patch dropping ashmem completely might take some time... until then enabling ashmem by default would be better!
(In reply to vrag from comment #44) > A patch dropping ashmem completely might take some time... until then > enabling ashmem by default would be better! That's not going to happen.
(In reply to Neal Gompa from comment #45) > (In reply to vrag from comment #44) > > A patch dropping ashmem completely might take some time... until then > > enabling ashmem by default would be better! > > That's not going to happen. The patch or enabling ashmem
(In reply to vrag from comment #46) > (In reply to Neal Gompa from comment #45) > > (In reply to vrag from comment #44) > > > A patch dropping ashmem completely might take some time... until then > > > enabling ashmem by default would be better! > > > > That's not going to happen. > > The patch or enabling ashmem Enabling ashmem.
Is there any progress on this?
is there any way I can help get Waydroid on Fedora? sounds like the 2 major issues of ashmem and binder are fading away?
After looking around and researching a little, it looks like Binder is not a problem. Only Ashmem is... Can I suggest that if Ashmem is only needed for older android apks that we concentrate on a MVP that doesn't include Ashmem, as later some workaround could be added if possible. That would allow us to concentrate on bundling a functional (MVP) version of waydroid, that you can enhance with Ashmem if you desire support.
(In reply to Rory Renton from comment #50) > After looking around and researching a little, it looks like Binder is not a > problem. Only Ashmem is... > > Can I suggest that if Ashmem is only needed for older android apks that we > concentrate on a MVP that doesn't include Ashmem, as later some workaround > could be added if possible. > > That would allow us to concentrate on bundling a functional (MVP) version of > waydroid, that you can enhance with Ashmem if you desire support. That's the plan. Binder got enabled in the Fedora kernels with 5.15.
(In reply to Neal Gompa from comment #51) > That's the plan. Binder got enabled in the Fedora kernels with 5.15. Great! Trying to get up to speed on the Ashmem problem, reading the waydroid page "...ships with a minimal customized Android system image based on LineageOS". Instead of making Fedora ready to run waydroid how it currently is, would it not be better to recompile the Android image waydroid uses to not reference Ashmem and instead use a GNU/Linux equivalent? then catch direct usage of Ashmem and redirect it to a CUSE for legacy apps. Anything I can help with? I'm pretty much a user-space only C programmer, but willing to learn.
(In reply to Rory Renton from comment #52) > (In reply to Neal Gompa from comment #51) > > That's the plan. Binder got enabled in the Fedora kernels with 5.15. > > Great! > > Trying to get up to speed on the Ashmem problem, reading the waydroid page > "...ships with a minimal customized Android system image based on > LineageOS". Instead of making Fedora ready to run waydroid how it currently > is, would it not be better to recompile the Android image waydroid uses to > not reference Ashmem and instead use a GNU/Linux equivalent? then catch > direct usage of Ashmem and redirect it to a CUSE for legacy apps. > > Anything I can help with? I'm pretty much a user-space only C programmer, > but willing to learn. Well, basically all that needs to be done is libcutils needs a version of https://android.googlesource.com/platform/system/core/+/refs/heads/master/libcutils/ashmem-dev.cpp using memfds, as I mentioned in comment 39. So once an implementation is contributed to AOSP and backported to LineageOS for Waydroid, we can start doing something here.
Any good news on this? > Well, basically all that needs to be done is libcutils needs a version of https://android.googlesource.com/platform/system/core/+/refs/heads/master/libcutils/ashmem-dev.cpp using memfds, as I mentioned in comment 39. Is there some ashmem 2 memfds guide I can follow to get the job done?
I've helped bring ashmem-less support to waydroid. It's now merged in master. For the record, aosp already had an ashmem-to-memfd translation layer which just needed to be enabled. There is one important bug with chromium which is being tracked here https://bugs.chromium.org/p/chromium/issues/detail?id=1296216 While that gets (hopefully) sorted out I'm working on packaging waydroid and the lineageos image for fedora.
you hero! I'm really excited about testing this. I'll help bug-test it, as I'm far too busy programming other things atm.
*** Bug 2055301 has been marked as a duplicate of this bug. ***
You may start trying out my copr https://copr.fedorainfracloud.org/coprs/aleasto/waydroid/
Would it be possible to add the Fedora 36 chroot?
(In reply to Markus Rathgeb from comment #59) > Would it be possible to add the Fedora 36 chroot? Not as simple as clicking a button since I edit the selinux-policy package which is on a different tag in f36, but i'll work on it
(In reply to Markus Rathgeb from comment #59) > Would it be possible to add the Fedora 36 chroot? Done
Thank you, I will give it a try.
Installation and init went fine. After some clicks in the full UI it seems the LineageOS ends in an endless loop. What I have done? Start some preinstalled apps (contacts, clock, browser) and at least the settings app. In the settings app I tried to add another language for the keyboard and while scrolling the list of languages it seems to crash. Where should it be reported at all? It could be related to * Fedora 36 beta * Waydroid on Fedora * Waydroid in general * ... The journal contains messages like this: Feb 26 20:53:31 m3800.localdomain init: Service 'bootanim' (pid 5958) exited with status 0 Feb 26 20:53:31 m3800.localdomain init: processing action (sys.boot_completed=1) from (/init.rc:815) Feb 26 20:53:31 m3800.localdomain init: starting service 'exec 19 (/bin/rm -rf /data/per_boot)'... Feb 26 20:53:31 m3800.localdomain libprocessgroup: Failed to make and chown /acct/uid_1000: Read-only file system Feb 26 20:53:31 m3800.localdomain init: createProcessGroup(1000, 6427) failed for service 'exec 19 (/bin/rm -rf /data/per_boot)': Read-only file system Feb 26 20:53:31 m3800.localdomain init: SVC_EXEC service 'exec 19 (/bin/rm -rf /data/per_boot)' pid 6427 (uid 1000 gid 1000+0 context default) started; waiting... Feb 26 20:53:31 m3800.localdomain init: Service 'exec 19 (/bin/rm -rf /data/per_boot)' (pid 6427) exited with status 0 waiting took 0.010000 seconds Feb 26 20:53:31 m3800.localdomain init: processing action (sys.boot_completed=1) from (/system/etc/init/flags_health_check.rc:7) Feb 26 20:53:31 m3800.localdomain init: processing action (sys.boot_completed=1) from (/system/etc/init/init.waydroid.rc:6) Feb 26 20:53:31 m3800.localdomain init: processing action (sys.boot_completed=1) from (/system/etc/init/logd.rc:32) Feb 26 20:53:31 m3800.localdomain init: starting service 'logd-auditctl'... Feb 26 20:53:31 m3800.localdomain libprocessgroup: Failed to make and chown /acct/uid_1036: Read-only file system Feb 26 20:53:31 m3800.localdomain init: createProcessGroup(1036, 6452) failed for service 'logd-auditctl': Read-only file system Feb 26 20:53:31 m3800.localdomain init: Service 'logd-auditctl' (pid 6452) exited with status 0 Feb 26 20:53:31 m3800.localdomain kernel: binder: 41489 RLIMIT_NICE not set Feb 26 20:53:31 m3800.localdomain kernel: binder: 41489 RLIMIT_NICE not set Feb 26 20:53:31 m3800.localdomain Waydroid.desktop[41078]: [20:53:31] Android with user 0 is ready Feb 26 20:53:32 m3800.localdomain kernel: binder: 41489 RLIMIT_NICE not set Feb 26 20:53:32 m3800.localdomain kernel: binder: 41489 RLIMIT_NICE not set Feb 26 20:53:32 m3800.localdomain apexd: Can't open /product/apex for reading : No such file or directory Feb 26 20:53:32 m3800.localdomain init: Received control message 'start' for 'gsid' from pid: 5990 (system_server) Feb 26 20:53:32 m3800.localdomain init: Received control message 'stop' for 'gsid' from pid: 5990 (system_server) Feb 26 20:53:32 m3800.localdomain init: Sending signal 9 to service 'gsid' (pid 1372) process group... Feb 26 20:53:32 m3800.localdomain libprocessgroup: Successfully killed process cgroup uid 0 pid 1372 in 0ms Feb 26 20:53:36 m3800.localdomain init: Received control message 'stop' for 'idmap2d' from pid: 5990 (system_server) Feb 26 20:53:36 m3800.localdomain init: Sending signal 9 to service 'idmap2d' (pid 92) process group... Feb 26 20:53:36 m3800.localdomain libprocessgroup: Successfully killed process cgroup uid 1000 pid 92 in 0ms The "Problem Reporting" GUI of fedora shows: "android.hardware.graphics.composer quit unexpectedly"
(In reply to Alessandro Astone from comment #58) > You may start trying out my copr > https://copr.fedorainfracloud.org/coprs/aleasto/waydroid/ I've sent your SELinux policy patch on BinderFS policy upstream: https://github.com/fedora-selinux/selinux-policy/pull/1100
tested it, working well so far!
(In reply to Alessandro Astone from comment #58) > You may start trying out my copr > https://copr.fedorainfracloud.org/coprs/aleasto/waydroid/ Thanks! Issues I noticed so far: * I can't drag applications across screens (although it works if I drag the application using the activities overview) * sometimes the physical keyboard stops working, and I need to restart the waydroid session to fix it * waydroid complains "Failed to start Clipboard manager service" -> "pip install pyclip" fixed this Kernel: 5.16.11-200.fc35.x86_64 Gnome: 41.6
For me it gets stuck here: ``` $ waydroid show-full-ui [02:07:50] Starting waydroid session ```
(In reply to thebudget72 from comment #67) > For me it gets stuck here: > > ``` > $ waydroid show-full-ui > [02:07:50] Starting waydroid session > ``` You'll find useful logs in `waydroid log` or `sudo waydroid logcat` or `dmesg` Some general issues may be: nvidia drivers (not compatible), waydroid-selinux not installed
Yeah I'm using NVIDIA drivers :) Will wait until they become compatible. Thanks!
Trying on Fedora 35 with latest updates and aleasto copr packages. Also, did `pip install pyclip` before launching `waydroid show-full-ui`. The command `waydroid log` includes: (000802) [10:48:13] New background process: pid=2534, output=background lxc-start: waydroid: utils.c: safe_mount: 1198 No such file or directory - Failed to mount "/dev/ashmem" onto "/usr/lib64/lxc/rootfs/dev/ashmem" And no android ui appears. I'll retry with Fedora 36 beta soon.
(In reply to Rich Lucente from comment #70) > The command `waydroid log` includes: > > (000802) [10:48:13] New background process: pid=2534, output=background > lxc-start: waydroid: utils.c: safe_mount: 1198 No such file or directory - > Failed to mount "/dev/ashmem" onto "/usr/lib64/lxc/rootfs/dev/ashmem" That is not relevant. Feel free to share full logs.
Created attachment 1864638 [details] lucente journal log 20220308
Created attachment 1864639 [details] lucente waydroid log 20220308
(In reply to Alessandro Astone from comment #71) > (In reply to Rich Lucente from comment #70) > > The command `waydroid log` includes: > > > > (000802) [10:48:13] New background process: pid=2534, output=background > > lxc-start: waydroid: utils.c: safe_mount: 1198 No such file or directory - > > Failed to mount "/dev/ashmem" onto "/usr/lib64/lxc/rootfs/dev/ashmem" > > That is not relevant. Feel free to share full logs. Logs attached. Please let me know if you need additional information.
(In reply to Rich Lucente from comment #74) > (In reply to Alessandro Astone from comment #71) > > (In reply to Rich Lucente from comment #70) > > > The command `waydroid log` includes: > > > > > > (000802) [10:48:13] New background process: pid=2534, output=background > > > lxc-start: waydroid: utils.c: safe_mount: 1198 No such file or directory - > > > Failed to mount "/dev/ashmem" onto "/usr/lib64/lxc/rootfs/dev/ashmem" > > > > That is not relevant. Feel free to share full logs. > > Logs attached. Please let me know if you need additional information. I don't have access to `journal log 20220308`, but the other one looks fine. Share `sudo waydroid logcat` too
Created attachment 1864675 [details] lucente journal log 20220308
(In reply to Alessandro Astone from comment #75) > (In reply to Rich Lucente from comment #74) > > (In reply to Alessandro Astone from comment #71) > > > (In reply to Rich Lucente from comment #70) > > > > The command `waydroid log` includes: > > > > > > > > (000802) [10:48:13] New background process: pid=2534, output=background > > > > lxc-start: waydroid: utils.c: safe_mount: 1198 No such file or directory - > > > > Failed to mount "/dev/ashmem" onto "/usr/lib64/lxc/rootfs/dev/ashmem" > > > > > > That is not relevant. Feel free to share full logs. > > > > Logs attached. Please let me know if you need additional information. > > I don't have access to `journal log 20220308`, but the other one looks fine. > Share `sudo waydroid logcat` too Sorry about that, I accidentally made that private. There should be a public attachment now. I also attached the `waydroid logcat` output as well (but from a separate session).
Created attachment 1864676 [details] lucente waydroid logcat 20220308
(In reply to Rich Lucente from comment #78) > Created attachment 1864676 [details] > lucente waydroid logcat 20220308 Relevant logs: 03-08 16:16:51.680 70 156 E GRALLOC-GBM: failed to create BO, size=1680x864, fmt=5, usage=4 03-08 16:16:51.680 87 749 E GraphicBufferAllocator: Failed to allocate (1680 x 864) layerCount 1 format 5 usage b00: 5 03-08 16:16:51.680 87 749 E BufferQueueProducer: [BootAnimation#0] dequeueBuffer: createGraphicBuffer failed 03-08 16:16:51.680 237 240 W EGL-MAIN: failed to dequeue buffer for window I see you're running this in kvm. You can try following this guide: https://docs.waydro.id/faq/get-waydroid-to-work-through-a-vm
(In reply to Alessandro Astone from comment #79) > (In reply to Rich Lucente from comment #78) > > Created attachment 1864676 [details] > > lucente waydroid logcat 20220308 > > Relevant logs: > 03-08 16:16:51.680 70 156 E GRALLOC-GBM: failed to create BO, > size=1680x864, fmt=5, usage=4 > 03-08 16:16:51.680 87 749 E GraphicBufferAllocator: Failed to allocate > (1680 x 864) layerCount 1 format 5 usage b00: 5 > 03-08 16:16:51.680 87 749 E BufferQueueProducer: [BootAnimation#0] > dequeueBuffer: createGraphicBuffer failed > 03-08 16:16:51.680 237 240 W EGL-MAIN: failed to dequeue buffer for > window > > I see you're running this in kvm. You can try following this guide: > https://docs.waydro.id/faq/get-waydroid-to-work-through-a-vm That worked! Thank you so much. I was running Fedora in virtualbox on my mac, so the changes in the FAQ were all that was needed.
I am on fedora 35 (fully updated), installed waydroid from the copr and I am getting Failed to get service waydroidplatform, trying again... when I run waydroid show-full-ui. That is because the "WayDroid container is STOPPED", running sudo waydroid container start shows [19:01:13] Failed to load ashmem driver [19:01:13] modprobe: FATAL: Module ashmem_linux not found in directory /lib/modules/5.16.13-200.fc35.x86_64 [19:01:13] Failed to load Ashmem driver and it hangs there. waydroid log shows the same: (019211) [19:01:13] % modprobe ashmem_linux modprobe: FATAL: Module ashmem_linux not found in directory /lib/modules/5.16.13-200.fc35.x86_64 (019211) [19:01:13] Failed to load ashmem driver (019211) [19:01:13] modprobe: FATAL: Module ashmem_linux not found in directory /lib/modules/5.16.13-200.fc35.x86_64 (019211) [19:01:13] Failed to load Ashmem driver (019211) [19:01:13] % chmod 666 -R /dev/binder (019211) [19:01:13] % chmod 666 -R /dev/vndbinder (019211) [19:01:13] % chmod 666 -R /dev/hwbinder (019211) [19:01:13] Container manager is waiting for session to load (013902) [19:01:13] Failed to get service waydroidplatform, trying again...
The SELinux policy changes have been merged into Fedora's SELinux policy: https://github.com/fedora-selinux/selinux-policy/commit/7235bb05e41e54e8723b10819e1326fbcb754c9a I hope to see it land soon in Fedora. :)
Are the NVIDIA proprietary drivers going to be supported? Will it be available on the Fedora official repos? :D
(In reply to thebudget72 from comment #83) > Are the NVIDIA proprietary drivers going to be supported? > > Will it be available on the Fedora official repos? :D You can fallback to software rendering with https://docs.waydro.id/faq/get-waydroid-to-work-through-a-vm
(In reply to thebudget72 from comment #83) > Are the NVIDIA proprietary drivers going to be supported? This is actually off topic for this bug. > Will it be available on the Fedora official repos? :D I think you know the answer to that.
After restarting, waydroid still doesn't launch but it says the container is running. I saw an issue on github that seemed similar https://github.com/waydroid/waydroid/issues/61 but it was mostly with AMD. I am running on integrated intel. I include my waydroid log & sudo waydroid logcat here, I don't really understand how to troubleshoot. If I shouldn't be commenting here, please correct me.
Created attachment 1866992 [details] chris_waydroid_log
Created attachment 1866993 [details] chris_waydroid_logcat
(In reply to chris from comment #88) > Created attachment 1866993 [details] > chris_waydroid_logcat You need to enable vsyscall32
> Are the NVIDIA proprietary drivers going to be supported? They will not. Android drivers are compiled in Bionic C. The Nvidia Proprietary drivers are compiled in glibc. This creates a compatibility problem. So unless a translation layer is created, it's completely out of anyone's hands except Nvidia. This issue is explained in [1]. You are best off using the opensource drivers if you want to use Nvidia with waydroid so you can use mesa for hardware acceleration. However; it currently seems broken [2] which leaves you with either your integrated GPU or software rendering at the moment. [1] https://github.com/waydroid/waydroid/issues/278 [2] https://wiki.archlinux.org/title/Waydroid#GPU_Requirements
For me it gets stuck on "[12:20:50] Starting waydroid session". I attach the logcat.
Created attachment 1869303 [details] logcat
I have upgraded the images with `waydroid upgrade`, rebooted, and it is now working :)
>> Will it be available on the Fedora official repos? :D > I think you know the answer to that. I actually don't know because the instructions from Astone say it contains proprietary software
(In reply to thebudget72 from comment #94) > >> Will it be available on the Fedora official repos? :D > > > I think you know the answer to that. > > I actually don't know because the instructions from Astone say it contains > proprietary software I don't speak for @leagal, but: The LineageOS images contain ffmpeg and possibly other projects with problematic licenses, it's hard to check them all since we're talking about ~800 individual components. Also there's a cmdline option to download images that include google proprietary software (google mobile services). As long as the download of non free software is user prompted and the rpm itself does not contain any links to it, it's not an issue. We will need to find a good way to handle it.
any news on this?
(In reply to thebudget72 from comment #96) > any news on this? I'm working with upstreams to solve some usability issues i consider important enough to hold from submitting the package to fedora.
Thanks Alessandro!
any news?
I've submitted a package review request at https://bugzilla.redhat.com/show_bug.cgi?id=2120119
Thank you everyone involved. Waydroid is in fedora.