ganache-2.3.0-linux-x86_64.appimage not starting

PsySc0rpi0n commented 4 years ago

ganache not starting from terminal with some sandbox error

## Expected Behavior

ganache start with GUI

Current Behavior

ganache terminates with the following error message: $ ./ganache-2.3.0-linux-x86_64.appimage [17798:0414/230526.577401:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run withting now. You need to make sure that /tmp/.mount_ganachIkGIQ3/chrome-sandbox is owned by root and has mode 4755. Trace/breakpoint trap (core dumped)

Possible Solution

Steps to Reproduce (for bugs)

Download Ganache from official site
chomod 755 ganache-2.3.0-linux-x86_64.appimage
./ganache-2.3.0-linux-x86_64.appimage

Context

I'm enrolled in a Blockchain online course and we are using ganache but I just can't make it run using the so called "one click" solution.

Your Environment

Version used: 2.3.0-linux-x86_64
Environment name and version (e.g. PHP 5.4 on nginx 1.9.1):
Server type and version:
Operating System and version:Debian Buster (10)
Link to your project:

davidmurdoch commented 4 years ago

Hey @PsySc0rpi0n. Sorry you are having trouble with the install!

Can you try https://github.com/trufflesuite/ganache/releases/tag/v2.1.2 and let me know if that works for you?

PsySc0rpi0n commented 4 years ago

Hey @PsySc0rpi0n. Sorry you are having trouble with the install!

Can you try https://github.com/trufflesuite/ganache/releases/tag/v2.1.2 and let me know if that works for you?

Yes, that image worked out of the box. So is this a problem with some misconfiguration on my side or something in the new .AppImage itself?

davidmurdoch commented 4 years ago

Seems to be related to this issue, and specifically this comment: https://github.com/electron/electron/issues/17972#issuecomment-487656378

davidmurdoch commented 4 years ago

This seems to be a misconfiguration of the AppImage in the latest release. There are some solutions offered in the thread I linked I'll start working on now. Would you mind if I sent you an updated release to test tonight or tomorrow (since I don't have Debian installed anywhere right now)?

vladimiry commented 4 years ago

The workaround is running it like ./ganache-2.3.0-linux-x86_64.appimage --no-sandbox.

PsySc0rpi0n commented 4 years ago

This seems to be a misconfiguration of the AppImage in the latest release. There are some solutions offered in the thread I linked I'll start working on now. Would you mind if I sent you an updated release to test tonight or tomorrow (since I don't have Debian installed anywhere right now)?

Sure. I'll be around tomorrow after work. 6:30 pm GMT + 1.

PsySc0rpi0n commented 4 years ago

The workaround is running it like ./ganache-2.3.0-linux-x86_64.appimage --no-sandbox.

Good. Nice to have a workaround until the issue is fixed. Hope you guys nail it fast! Thanks

vladimiry commented 4 years ago

Here is some info how to embed the --no-sandbox arg in the AppImage package:

unpack the package ./ganache-2.3.0-linux-x86_64.appimage --appimage-extract
replace exec "$BIN" lines in ./squashfs-root/AppRun file to exec "$BIN" --no-sandbox
pack it back ./appimagetool-x86_64.AppImage -n --comp xz ./squashfs-root package-name.appimage (take appimagetool-x86_64.AppImage from https://github.com/AppImage/AppImageKit/releases/tag/continuous)

If you face AppImages require FUSE to run-like error during packing the image, unpack the tool first to some dir ./appimagetool-x86_64.AppImage --appimage-extract and then run its ./squashfs-root/AppRun script directly.

davidmurdoch commented 4 years ago

Thanks @vladimiry! I think we're going to use the solution Signal-Desktop is using until I can implement a proper .deb distribution pipeline (https://github.com/signalapp/Signal-Desktop/blob/58f3592b9fa1962fcafbcc793532b262225ac5a4/patches/app-builder-lib%2B22.3.6.patch).

davidmurdoch commented 4 years ago

I installed Debian 10 and tested it myself today. Looks like the Signal-Desktop solution doesn't work for AppImage, so I ended up applying a --no-sandbox workaround in an afterSign hook: https://github.com/trufflesuite/ganache/commit/c9016331bab3bb3df72923d848e56c33f29cd708

vladimiry commented 4 years ago

Looks like the Signal-Desktop solution doesn't work for AppImage

Correct, --no-sandbox arg solution is normally used only for Snap and AppImage electron-based packages.

I ended up applying a --no-sandbox workaround in an afterSign hook: c901633

The solution of using preloader bash script has some flaws. I remember at least one: Cinnamon panel shows 2 icons for the Electron-based programs that use preloader bash script workaround (I didn't test the case myself but I faced the reported issue).

PsySc0rpi0n commented 4 years ago

I guess, as the issue is now closed, that no more help from me (Debian user) is needed. right?

Thanks everyone.

davidmurdoch commented 4 years ago

@vladimiry ah, well that's unfortunate! Any idea when and how the AppCode is generated. It looks like it is generated by the desktopintegration file in AppImageKit here: https://github.com/AppImage/AppImageKit/blob/8a595740276e3a4dbd6541f25b5380548b442d3b/desktopintegration) but in the latest versions of AppImageKit this file doesn't exist. My hope was that I could patch this batch file after npm install (via a postinstall script).

However, I imagine it's been compiled into app-builder-bin binaries, in which case updating app-builder to accept runtime args that can be passed in to the app-builder-lib binaries is probably required. @develar, has this been looked into? Would a PR be welcome?

vladimiry commented 4 years ago

@davidmurdoch https://github.com/electron-userland/electron-builder/pull/4496

davidmurdoch commented 4 years ago

@vladimiry I actually tried that PR as well as a similar approach (here: https://github.com/trufflesuite/ganache/commit/3429195f6345478e44090b198dc2d053bb386d5f#diff-47bc9e18008f64ed83c9a8d01fe43d31R10) but it this doesn't work, at least on Debian 10 (error: The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_ganachfn96Sv/chrome-sandbox is owned by root and has mode 4755.).

What does work is injecting in my own AppRun file into ./dist/linux-unpacked with --no-sandbox already embedded during the afterSign hook:

https://github.com/trufflesuite/ganache/commit/405362b690f7ffbcf1e7f3c5e193db94454327f1#diff-da66bc1151f9c29ebe3dd9be0e400994R16-R21

I still need to do some additional testing, but so far, it seems to be working for AppImages on Debian 10.

vladimiry commented 4 years ago

@davidmurdoch to recap, I prefer --no-sandbox arg to be embedded into the Snap and AppImage packages and SUID bit set for other package types (deb, pacman, etc). This approach has been working well in https://github.com/vladimiry/ElectronMail. If you embed the --no-sandbox arg into the foe example deb package you disable the sandboxing even though it could work there.

davidmurdoch commented 4 years ago

I prefer --no-sandbox arg to be embedded into the Snap and AppImage packages

@vladimiry AFAIK, this solution should be doing the same thing as what you've done in ElectronMail, but it doesn't require unpacking and repacking. Downside is that my AppRun file is now static, and a future update could potentially overwrite my custom AppRun file when it is packaged into an AppImage.

If you embed the --no-sandbox arg into the foe example deb package you disable the sandboxing even though it could work there.

We are currently only distributing AppImage, so I'm not worried about deb, snap, etc just yet.

Thanks for all your help, btw!

vladimiry commented 4 years ago

I just put a recap in previous message since I noticed Debian was mentioned. It might be I was somehow sloppy reading all the messages here.

trufflesuite / ganache-ui