busybox not found from the expected path

[rubysm]

Busybox NDK intsalled but it replies with not found from expected path,How to set NDkbusybox as primary.

[jjkola]

Thanks for the report. Can you run chroot-distro env and attach the output here? Also, can you tell me about your device? Model, Android version, and if you have a custom rom. Just to clarify things, did you install your Busybox separately, or are you using Busybox provided by your root solution?

[rubysm]

1.builtin busybox interferes with ndkbsybox bcoz it comes in path first ,so can u modify the script to lookin bin directory for ndkbsybox or else path variable should be modified to checkin bin directory first.

2.how to shutddown distro? from inside.

[rubysm]

update distro links

[jjkola]

Thanks for the reports. I would prefer if unrelated issues are reported separately.

Regarding the original issue, I'm still waiting for the information I have asked.

Regarding the first point, this has been taken care of in the script.

Regarding the second point, if there is no extra processes running then simple exit is sufficient. If there is extra processes running then you have to use the facilities provided by the specific rootfs and/or create your own scripts to help with initialization/shutdown of the rootfs.

Regarding the distro download links, I'm aware of this, and there is several reports about this. Unfortunately both of us maintainers has been busy IRL so we haven't been able to contribute much. Also, I have had to implement big feature requests which has taken all the available time. Thus I have had to prioritize things and unfortunately this has been rather low on the list (even though I know that it is not a big job, at least in most cases).

[rubysm]

ok!
busybox should be explictly called with its path or else native busybox interfers and make the script useless.

[jjkola]

Just to clarify, the warning should be issued only if Busybox wasn't found from expected places. The script will still use the found Busybox to ensure as consistent scripting environment as possible. If you run the above mentioned chroot-distro env command you will know from where the script will use it.

We would love to support every environment available but there is only so much time available for us to maintain thus we need to set a baseline, and that baseline is currently having a separately installed Busybox for Android NDK Magisk module. The warning just means that the maintainers have not actively tested the currently used combination, and rely on other users to report problems.

If you feel that the current warnings are too intrusive and/or could use better wording, suggestions are welcome. Please do note that after successful installation there will be no warnings.

[jjkola]

But, still I would like to know the information requested originally to ensure that there is no problems. If you don't want to share it, no problem, but please do inform about it so that I can close the issue as currently there is no known bug/issue about this. If you have a valid suggestion about the warning then I will try to incorporate it when I will have time (currently this is even lower priority than before mentioned download link fixing, unless you can prove that there is a bug).

[rubysm]

$chroot-distro env
[

Script: /system/bin/chroot-distro
Version: 1.3.0
Versioncode: 12
md5 hash: 8101eb5286a8b5c647a409debccb0da1
Toybox version: toybox 0.8.4-android
busybox => '/data/mkuser/usr/bin/busybox'
Busybox version: BusyBox v1.36.1.1 topjohnwu (2024-10-06 01:38:43 PDT) multi-call binary.
chroot => '/system/bin/chroot'
lsof => 'busybox lsof'
Magisk installed (28.1:MAGISK:R)
Busybox for Android NDK Magisk module installed
Linux 4.9.191-lateM+ #7 SMP PREEMPT Thu Sep 1 21:53:56 CEST 2022 aarch64 Android
PATH=/data/mkuser/usr/bin:/data/mkuser/root/.local/bin:/system/bin:/sbin:/vendor/bin:/system/sbin:/system/xbin:/system/product/bin:/system/usr/share/bin-get/bin:/system/system_ext/bin

]

mkuser dir contains symlink of builtin busybox thats why it called first.

[jjkola]

Thanks for all the extra information. If you want, could you at least provide Android version, and if you are using custom rom (and if yes, what custom rom), so I a have something to compare against if there is more issues related to this? Also, can you run

ls -l /data/mkuser/usr/bin/busybox

so that I can know where does it point? I would like to keep the implementation as simple as possible. Thus, if I can make it work just by dereferencing the link then I would rather do it so.

I did some research on that mkuser folder and I'm left wondering if you have multiple user profiles in use. Would you care share information about this? Or, do you have MMRL installed? It may help with developing a fix for your situation.

[jjkola]

You have to understand that I have only one old device where I can test things (Magisk without anything else except Busybox Android ndk module). This means that if somebody encounters a problem then I have to get enough information about the situation that I can first understand the issue.

After that I will need to get enough information to fix the issue while keeping the existing users happy. Depending on situation the change may be small, or big, but the effect can be also small, or big, regardless what size the change is. So, a one liner can be a point release, or it can change the major number (i.e. backwards incompatible change).

The current situation is that I have enough information to understand the issue, but don't have enough information to confidently fix the issue without causing problems to other users. I can understand if you don't want to share information because of privacy concerns, but to solve this issue I need to know at least where does /data/mkuser/usr/bin/busybox point to. It would also be nice if you could share if you have MMRL installed, as currently based on my research this may be the source for that path.

[jjkola]

@nglmercer @vince06fr @DeraidSeven @sabamdarif @anaxonda @defectly @univers629 @hopez13

Sorry to bother you guys, but if you have a little bit of time, I would appreciate if you could check if the busybox command used by chroot-distrois a link or not. Also, if it is a link then would appreciate if you could tell the source path and destination path. You can find out the busybox path by running chroot-distro env.

This would help me assess the problems caused by derefencing busybox if it is found out to be a link. Also, if you can share if you have /data/mkuser/... in the PATH (can be seen from env command). I'm also interested in knowing if you have MMRL installed.

The more data points I get the better, so even if you only have information that it is not a link, then that is ok also.

[defectly]

@nglmercer @vince06fr @DeraidSeven @sabamdarif @anaxonda @defectly @univers629 @hopez13

Sorry to bother you guys, but if you have a little bit of time, I would appreciate if you could check if the busybox command used by chroot-distrois a link or not. Also, if it is a link then would appreciate if you could tell the source path and destination path. You can find out the busybox path by running chroot-distro env.

This would help me assess the problems caused by derefencing busybox if it is found out to be a link. Also, if you can share if you have /data/mkuser/... in the PATH (can be seen from env command). I'm also interested in knowing if you have MMRL installed.

The more data points I get the better, so even if you only have information that it is not a link, then that is ok also.

i have MMRL version 2.20.21 installed

:/ # chroot-distro env
Script: /system/bin/chroot-distro
Version: 1.2.3
Versioncode: 11
md5 hash: 8101eb5286a8b5c647a409debccb0da1
Toybox version: toybox 0.8.6-android
busybox => '/system/bin/busybox'
Busybox version: BusyBox v1.36.1-osm0sis (2023-09-02 19:01:41 ADT) multi-call binary.
chroot => '/system/bin/chroot'
lsof => 'busybox lsof'
KernelSU installed (version not known)
Busybox for Android NDK Magisk module installed
Linux 4.14.349-openela~SLEEPY #1 SMP PREEMPT Wed Jul 31 14:08:05 UTC 2024 aarch64 Android
PATH=/debug_ramdisk:/sbin:/sbin/su:/su/bin:/su/xbin:/system/bin:/system/xbin:/data/adb/ksu/bin
:/ #

[jjkola]

Thanks, and is it link? What does ls -l /system/bin/busybox say? I would assume that it is not a link, but just in case.

[defectly]

Thanks, and is it link? What does ls -l /system/bin/busybox say? I would assume that it is not a link, but just in case.

:/ # ls -l /system/bin/busybox
-rwxr-xr-x 1 root root 2143584 2024-09-04 08:37 /system/bin/busybox
:/ #

[LovecraftianGodsKiller]

I just installed the BusyBox module and this module and am experiencing the same thing.

chroot-distro env is detecting BusyBox in the right location but when I run chroot-distro I get this error

Warning: You are using Magisk/KernelSU/APatch without Busybox for Android NDK installed.
You may experience bugs as this is community supported environment.

[jjkola]

Everyone who wants to report about the issue, please, include the output of the chroot-distro env and also, ls -l <location of busybox from previous command>. Also, please include if you have MMRL installed, and if you have, then what version.

As far as I know there is three different issues which can come into play:

1. No Busybox for Android NDK installed
2. Busybox for Android NDK installed but for whatever reason is not in the PATH (and no other busybox is in PATH)
3. Busybox for Android NDK installed but something else is in the PATH which interferes in the current version to find the correct version

The first case is about being community supported (we rely on user reports to spot problems with this case). The second one should not cause a warning as the script will detect the module, and use it.

The current issue is for the third case. And for this I need enough information to fix the issue. Also, if possible please use the latest version for the reporting to ensure that all the relevant information is available for reporting (older versions may not output all the needed information as env command may be updated to include more information with the newer versions (depending on bug reports)).

[jjkola]

This issue has got myself thinking about the implementation. When I originally added the check for the busybox I wanted to

1. Ensure that there is a known version (Busybox for Android NDK Magisk module)
2. To provide the least surprise to the user by using the busybox found in PATH unless there was known problems
3. To get a quicker notification about problematic environments

Also, when I originally implemented it I was under impression that there isn't much variation about the busybox location (apart from the shell affecting it, at most), and I thought that I would be able to quickly whip up a fix, if it didn't work.

Given the current situation there is clearly quite much variation, and I don't have too much time to spend on this project, I'm starting to lean on the side that if Busybox for Android NDK module is found, and the busybox from PATH is unknown then the script will prefer the known version (but maybe with a note about it so that you guys will hopefully report those cases).

This way you guys will not be prevented from using the script while hopefully ensuring that the problems will be reported. This change will be now my first priority to do as I don't want to prevent people from using the script.

[pluseach]

i think we should provide our own BusyBox if that's possible. we could try getting it from BusyBox for Android NDK. the module installer with customize.sh could first check if BusyBox for Android NDK is installed. if it is, the BusyBox we obtained from BusyBox for Android NDK should not be installed, and vice versa.

what do you think? this way we can avoid all these BusyBox-related headaches. @jjkola

[pluseach]

If there are other BusyBox modules installed that's not Busybox Android NDK by osm0sis, we'll notify users about potential conflicts and inform them that their existing BusyBox will be replaced with our provided version.

[jjkola]

I don't think I want add our own Busybox, or that it is installed automatically unless it is by using package meta-data (i.e. the packaging system installs it).

[jjkola]

I have now made a first implementation but since I have not tested the change in any way, I will not yet publish the code. I'll try to test it as soon as possible.

[pluseach]

well.. sounds good, no need to rush on the code - better test it properly first.