Unable to extract new 1.10.1 bootstrap in 2.0
hhocker opened this issue · comments
@feelfreelinux,
I feel bad being the first one to report an error to you and I will do more investigating. I know you have put a lot of work into 2.0 and I hate to start piling in the bug reports. However I am not sure if this is due to the upgrade (which I said yes to clearing) or something with my environment.
Device: Fire HD 8 (Android 9, arm7a)
Version: 2.0.0
Error:
Exception:
java.lang.RuntimeException: Process exited with error code 126. [No Bootstrap detected, extractingUnable to chmod
When I pull down the new proot bootstrap it downloads and tries to extract. However I can see that there is a few lines above the strack trace the following
Unable to chmod ..//serialpipe: Permission denied
bad mode
entrypoint.sh[33]: ../bin/minitar: cant execute: Permission Denied
entrypoint.sh[33]: cat: <stdout>: Broken pipe
entrypoint.sh[62]: ./proot: cant execute: Permission Denied
An exception has occurred at:
......
at com.octo4a.utils.ProcessUtilsKt.waitAndPrintOutput(ProcessUtils.kt:43)
......
I am wondering if there is a storage permission error or something else happening. I will try another device and will also fully uninstall and reinstall the app. Thanks again for the bold work on this new design.
I feel bad being the first one to report an error to you and I will do more investigating. I know you have put a lot of work into 2.0 and I hate to start piling in the bug reports. However I am not sure if this is due to the upgrade (which I said yes to clearing) or something with my environment.
Haha, I really appreciate the help, and thanks a lot for the report. This is most likely a regression against the earlier release, and to me feels like an invalid chmod setting, set in the bootstrap entrypoint. Previous releases used 700 mode during setup, and it makes a lot of sense - we cant exactly set the application folder to a 777 mode, as only the application / owner can get access there.
I applied a possible fix in feelfreelinux/octo4a-bootstrap-builder@3b5b370
When the https://github.com/feelfreelinux/octo4a-bootstrap-builder/actions/runs/9138677337 build goes through, a "prerelease" build should appear in the app - please try to install that.
Sadly that didnt work. I think that "bad mode" error is actually the second chmod failing. The 777 would have done the same thing as +rx would have done if it had gone through. See https://stackoverflow.com/questions/9285903/adb-shell-giving-bad-mode-when-executing-chmod-under-su#comment11711815_9285903 for an explanation on that one. Could be that the alpine/proot chmod doesn't understand +rx?
I personally would do the following:
Get the right bin and libexec folders in place, chmod those as 777 chmod +R 777 ./bin && chmod +R 777 ./libexec so just the executables are elevated. If need be you could do a 744 over the whole folder (owner execute, group read, any read) then 777 the executables directly). Sorry to have you keep trying.
Sounds like a good idea - will prepare a fix in 30ish minutes :)
Manually edited out the entrypoint in armv7a's prerelease build:
You are right about the +rx notation :) Although, the -R 700 earlier should've caught it - I think the actual issue might come from the serialpipe being a fifo created by the app on runtime - in earlier builds it was absent during the installation step. With these changes, it should be completely ignored, and hopefully it works fine. To recheck this, try to make a fresh install of the pre-release bootstrap.
@feelfreelinux I didnt get a chance to test today due to being on a big project but that worked. It successfully downloads ad unpacks. No issues.
One small thing to think about for 2.1 (and I will see if I can find why it did this) is that the bootstrap loads and boots into octoprint, then for some reason when you say "finish" it restarts the proot and boots octoprint again. Not sure if that was intentional or if we should dig in and see where that double boot happens. If it is doing that intentionally then never mind. I think you have succeeded on your quest for this release.
Great, thanks for reporting :) Released a new bootstrap with this fix. The double boot issue is something I noticed with the new version too - mostly harmless right now, but looks like I'm not properly reporting the state of octoprint being booted, right after the installation finished. Will take a look at it at some point :)