nexus_wallet-Linux-1.1.0.AppImage doesn't work - critical error

[github12101]

Describe the bug
Just downloaded nexus_wallet-Linux-1.1.0.AppImage on Linux MX (Debian Stretch with improved GUI). Wallet fails with critical error.

To Reproduce

$ wget https://github.com/Nexusoft/NexusInterface/releases/download/v1.1.0/nexus_wallet-Linux-1.1.0.AppImage
$ chmod +x nexus_wallet-Linux-1.1.0.AppImage
$ ./nexus_wallet-Linux-1.1.0.AppImage 
Gtk-Message: 13:34:45.524: GtkDialog mapped without a transient parent. This is discouraged.
r: 0
License accepted
[23280:0720/133448.229231:FATAL:setuid_sandbox_host.cc(157)] 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_nexus_9yJ2Ut/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

This is stock Linux, nothing has been changed and I have no knowledge of any custom changed made to sandbox helper or whatever that is.

Expected behavior
nexus-wallet command should start wallet. I can see Licence Agreement I can click Yes, but it fails with error

Screenshots
not required

Desktop (please complete the following information):
$ uname -a
Linux mx 4.19.0-5-amd64 #1 SMP Debian 4.19.37-2~mx17+1 (2019-05-15) x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: MX
Description: MX 18.3 Continuum
Release: 18.3
Codename: Continuum

All packages are from Debian Stretch.

[github12101]

Please note, previous version of the wallet has worked on this machine without this error (Window worked and GUI was present, but wallet failed to synchronize). This is potentially a regression from previous version.

[l8nit3tr0ubl3]

From my own research into the issue, it looks like electron issue 17972 may be the culprit for the current Linux issues.
To the devs:
it seems that downgrading the electron builder version back to 4.xx was the workaround in the linked thread.

[github12101]

Just installed brand new Debian 10.0 Buster on AMD64 machine.
Results:

$ ./nexus_wallet-Linux-1.1.0.AppImage 
r: 0
License accepted
[2742:0728/145021.373257:FATAL:setuid_sandbox_host.cc(157)] 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_nexus_ZSATul/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

[l8nit3tr0ubl3]

@pioruns
Yes, I'm fairly certain it is an issue with the version of "electron builder" that is being used. Many other programs using that dependency have this issue. Chances are a simple rollback of the commit that updated the electron version should fix this issue.

Basically, this is not an issue with the wallet, but with one of the dependencies.

[KenCorma]

@pioruns
I am going to update the electron-builder package and send you a email.

[github12101]

Thanks, I sent you back the results - no success as of yet!

[l8nit3tr0ubl3]

had a thought and some free time.... and came up with this:
Electron 5.x.x seemed to be the issue, so I went into the package.json and package-lock.json, and updated the electron , electron-builder packages to the newest.

• electron-builder version=21.2.0 os=4.4.0-18362-Microsoft
• loaded configuration file=package.json ("build" field)
• writing effective config file=release/builder-effective-config.yaml
• packaging platform=linux arch=x64 electron=6.0.0 appOutDir=release/linux-unpacked
• building target=AppImage arch=x64 file=release/nexus_wallet-Linux-1.1.0.AppImage
• building target=deb arch=x64 file=release/nexus_wallet-Linux-1.1.0.deb

Aaaand...... ive got a running and syncing linux wallet on 1.1.0, 3.0.2, and ubuntu 18.04, currently syncing and downloading the bootstrap!

changes were.....
package.json:
"electron": "^6.0.0",
"electron-builder": "^21.2.0"

package-lock.json:
"electron": {
"version": "6.0.0",
"resolved": "https://registry.npmjs.org/electron/-/electron-6.0.0.tgz",
"integrity": "sha512-JVHj0dYtvVFrzVk1TgvrdXJSyLpdvlWNLhtG8ItYZsyg9XbCOQ9OoPfgLm04FjMzKMzEl4YIN0PfGC02MTx3PQ=="

"electron-builder": {
"version": "21.2.0",

"resolved": "https://registry.npmjs.org/electron-builder/-/electron-builder-21.2.0.tgz",

"integrity": "sha512-x8EXrqFbAb2L3N22YlGar3dGh8vwptbB3ovo3OF6K7NTpcsmM2zEoJv7GhFyX73rNzSG2HaWpXwGAtOp2JWiEw==",

On first run, connection to core hangs, but a second load connects and boots fine!

[github12101]

That's great :) Can this be packaged into AppImage? I am happy to test once ready.

[l8nit3tr0ubl3]

yes I can send it over one minute. Im not sure why, but it still seems to not like having a backup added in (old wallet.dat) and there is still connection to core issues on reloads, but it opens now!

appimage link and VT results virustotal and deb link and VT results virustotal

[github12101]

Will test that in a minute, thanks!

By the way, why this is not tagged as BUG? Why no one is assigned to this issue?

EDIT:
Both links goes to .deb file, file is exactly the same (sha256sum). Can you check please? If you can re-upload AppImage. Also, your virustotal deb link goes to old 1.1.0 file, not the one you just uploaded. The one you uploaded, deb 1.1.1 is here: https://www.virustotal.com/gui/file/3c1db6c93f33a1947debb70f9b279898fd3492a663589cfb82748ffe94ad3602/detection

[github12101]

Ok, tried to test .deb file, result:

# gdebi nexus_wallet-Linux-1.1.1.deb 
Reading package lists... Done
Building dependency tree        
Reading state information... Done
Reading state information... Done
This package is uninstallable
Dependency is not satisfiable: gir1.2-gnomekeyring-1.0

Can't install, depends on obsolete package which doesn't exist in Debian Buster 10 anymore.
I never thought Debian Stable will be ahead of something, they were always miles away with versions of the software. Well, this time they are ahead.

Let me know about AppImage, I will check that next:)

[l8nit3tr0ubl3]

sorry, at the time I was using anydesk from my phone lol so some of the links got messed up, appimage should be here https://drive.google.com/open?id=1UaR-g_D1ApBZzy5sXd-GLqd89lnP17GA

however these will not fix your 'gir1.2' issue, only the subsequent SUID sandboxing issues.
for the gir1.2 issue try:

wget http://mirrors.kernel.org/ubuntu/pool/main/libg/libgnome-keyring/gir1.2-gnomekeyring-1.0_3.12.0-1build1_amd64.deb

sudo dpkg -i gir1.2-gnomekeyring-1.0_3.12.0-1build1_amd64.deb
`
Also, ive been testing on ubuntu, so im spinning up a Debian machine now to get some more testing in on a similar setup to yours.

[github12101]

You linked nexus_wallet-Linux-1.1.0.AppImage, downloaded that, no luck.

$ chmod +x nexus_wallet-Linux-1.1.0.AppImage 
pioruns@debian:~/Downloads$ ./nexus_wallet-Linux-1.1.0.AppImage 
r: 0
License accepted
[6946:0805/213106.316919:FATAL:setuid_sandbox_host.cc(157)] 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_nexus_otbI6a/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

[l8nit3tr0ubl3]

So youve passed the gir1.2 issue? those instructions worked? heres a screen of it syncing on 18.04.... i will reupload a new copy, maybe i choose a bad file for the AppImage
https://drive.google.com/file/d/1WSBwL974qcqQR0fiMky6GlMr9lCT7T5Z/view?usp=sharing

[github12101]

Just downloaded your new file nexus_wallet-Linux-1.1.1.AppImage. Result:

$ chmod +x nexus_wallet-Linux-1.1.1.AppImage 
pioruns@debian:~/Downloads$ ./nexus_wallet-Linux-1.1.1.AppImage 
[7109:0805/223241.679055:FATAL:setuid_sandbox_host.cc(157)] 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_nexus_zHv662/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

Also, I can't just install gir1.2-gnomekeyring-1.0_3.12.0-1build1_amd64.deb into my system, it depends on other components. Most likely source depo would need to be added in order for this to work, or installation of few more packages, but that's not the path we should be taking - Nexus is depending on obsolete library in the first place.

`# dpkg -i gir1.2-gnomekeyring-1.0_3.12.0-1build1_amd64.deb
dpkg: warning: 'ldconfig' not found in PATH or not executable
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable
dpkg: error: 2 expected programs not found in PATH or not executable
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin
root@debian:/home/pioruns/Downloads# gdebi gir1.2-gnomekeyring-1.0_3.12.0-1build1_amd64.deb 
Reading package lists... Done
Building dependency tree        
Reading state information... Done
Reading state information... Done
This package is uninstallable
Dependency is not satisfiable: libgnome-keyring0 (= 3.12.0-1build1)`

No idea why dpkg -i doesnt work as intended, but gdebi shows what is going on.

[l8nit3tr0ubl3]

eating some dinner quick, and then im on it! :) Ill grab a copy of MX and add it to my dev machine quick. Will update if i resolve the issue for your system specifically. But so far for ubuntu the SUID issue seems resolved, if an actual dev can verify thatd be great. And once i have MX working ill put it into a merge request for mainstream use if the devs see fit.

[github12101]

AFAIK, Latest MX Linux is based on Debian Oldstable (Stretch), that's why I moved out from it, because I realized, that recommened way to upgrade MX is a fresh install O_o (once they release a new one based on Buster). Scrapped MX, went to base system - Debian Buster and it works perfectly, will leave my server with it for years to come.

I am testing on VM anyway, I will be happy to test on other systems once you have a piece of code which needs more extensive QA :)

[l8nit3tr0ubl3]

Closed pull request as it doesn't fix Debian issues and id like to have all fixes in one pull.

I have the same issue you have with buster, however i have skipped the gir1.2 issue completely by using a gnome edition of Debian 10. So that seems to be only an issue on non-gnome distros.

However, my update fix does not work on a vanilla Debian Buster VM even though it seems to be working great on ubuntu 18.04.
Setting up a 19.04 VM to see if it works there out-of-box and then plod on ahead with a Debian fix if im able

[update]
ubuntu 16.04,18.04, and 19.04 works out-of-box with my fixes, so just gotta figure out the debian 9 & 10 issue :)

[update 2]
Having a tough time figuring out the debian issue, so pushing the ubuntu fix untill i figure it out, or the devs beat me to it :)

[github12101]

Well that's interesting! Debian 10 Gnome version somehow satisfies dependency, which is uninstallable on Debian 10 MATE, with same repositories? I rather think that AppImage worked there for you, but not .deb file? .deb file should remain uninstallable as it doesn't exist on Debian repo, you can try here https://www.debian.org/distrib/packages these packages doesn't exist in Buster.
Please confirm, I can try your AppImage on Debian 10 Gnome it that's what you did and it worked for you.

[l8nit3tr0ubl3]

No progress on Debian at all. Its still stuck at the SUID issue, however it has passed the gir1.2 dependancy issue (like you said, just the AppImage ). After work today, I have a few more ideas to try, but after that ill leave it to the real devs :)

[KenCorma]

Hey @l8nit3tr0ubl3 thank you so much for your investigating, I does seem like electron 5 is being funky. We can look into upgrading it to 6. I think 5 to 6 will be easy compared to 4 to 5 where there were dep issues.

[l8nit3tr0ubl3]

So, it would seem 5-6 still has issues on debian based distros (SUID above), and any non-gnome based distro (gir1.2 above) however I have just tested a version on Debian with downgraded 5-4 electron and no other changes, and it works so far on Debian 10!!! just have to test ubuntu then ill send a pull request :)

[KenCorma]

Awesome, just let me know when the pull request is finished and I can go over it with the team.

[l8nit3tr0ubl3]

Heres an AppImage for anyone who wants to test Google Drive and heres a listsing of all the compiled binaries as i test them google drive folder
(disclaimer - this is a 3rd party edited wallet, not yet reviewed by the official dev team! any issues are likely my fault)
Tested and working on Debian 10, ubuntu 18.04, and currently building to test on windows, after which ill load it onto the hackintosh and get all systems tested.

Once all test clean i will re-issue the pull request from a cleaned up fork for review.
BUT, worth mentioning, this only fixes AppImage, not .deb and only on gnome based systems!

UPDATE
windows works fine, now onto mac....... mac tested and working

[l8nit3tr0ubl3]

if I understand correctly, that is an option for how many rpc request can be handled concurrently. It is not the number of cores/threads in use at any one time, just a maximum number if multiple rpc requests are made all at once. It is built in to the wallet, or possibly dynamic based on system specs, but is not something I changed in my update.

[github12101]

ok thanks :)

So, testing is done at this point, we can wait for some of your changes to be pulled into main repo, right? I will be happy to test again once official builds are out.

And certainly fail of Nexus Core at first run could be looked at.

[l8nit3tr0ubl3]

I wonder if the missing/unreadable settings.json is the cause of the core hanging? At which point a simple re-scan for the file after creation should fix it, or even a hardcoded core reboot after file creation.....

[KenCorma]

Have you seen this?
electron/electron#17972 (comment)

[KenCorma]

Also have you by any chance tried with electron 6? Would rather upgrade than downgrade to 4.

[l8nit3tr0ubl3]

Doing a chown & chmod does not work in our case, the chromium sandbox folder is created in /tmp/.mount_nexus_[randomstring] and the random string changes each time.

I believe a downgrade or fully disabling the sandbox are the only options at this point (will test disabling sandbox later this evening)
If so, I'll setup a PR for both and the team can decide which has less undesirable impact.

[l8nit3tr0ubl3]

@pioruns
Please try a fresrun of the original AppImage (1.1.0) by the dev team. BUT, before running it run the command
sudo sysctl kernel.unprivileged_userns_clone=1
All should run well :)

[github12101]

I am not in sudoers file, had to use "su -" and also install procps package first.

Result:

$ su -
Password: 
root@debian:~# sysctl kernel.unprivileged_userns_clone=1
kernel.unprivileged_userns_clone = 1
root@debian:~# exit
logout
pioruns@debian:~$ ./nexus_wallet-Linux-1.1.0.AppImage 
17:56:22.538 › File server listening on port 9331!
Error reading JSON at /home/pioruns/.config/Nexus Wallet/settings.json : Error: ENOENT: no such file or directory, open '/home/pioruns/.config/Nexus Wallet/settings.json'
Error reading JSON at /home/pioruns/.config/Nexus Wallet/settings.json : Error: ENOENT: no such file or directory, open '/home/pioruns/.config/Nexus Wallet/settings.json'
Error reading JSON at /home/pioruns/.config/Nexus Wallet/settings.json : Error: ENOENT: no such file or directory, open '/home/pioruns/.config/Nexus Wallet/settings.json'
Error reading JSON at /home/pioruns/.config/Nexus Wallet/settings.json : Error: ENOENT: no such file or directory, open '/home/pioruns/.config/Nexus Wallet/settings.json'
17:56:23.164 › Checking if core binary exists: /tmp/.mount_nexus_DCaZiT/resources/assets/linux/cores/nexus-linux-x64
17:56:23.171 › Core binary exists
17:56:23.172 › Core Manager: Data Directory path not found. Creating folder: /home/pioruns/.Nexus
17:56:23.172 › Core Parameters: -daemon,-avatar,-server,-rpcthreads=4,-fastsync,-datadir=/home/pioruns/.Nexus,-rpcport=9336,-verbose=0,-stake=1
17:56:23.172 › Core Manager: Starting core
17:56:23.197 › Core Manager: Core has started (process id: 4712)
pos 456 170
Error reading JSON at /home/pioruns/.config/Nexus Wallet/settings.json : Error: ENOENT: no such file or directory, open '/home/pioruns/.config/Nexus Wallet/settings.json'

Beautiful.

[github12101]

I also tried nexus_wallet-Linux-1.1.0.deb, but that still requires gir1.2-gnomekeyring-1.0 which is uninstallable.

[l8nit3tr0ubl3]

Great! Now I'll start working on the 1st run core lag, and some of those warnings and errors that show in your log :)

I dont recommend closing this as solved yet though, as we only have a workaround at this point and not a permanent, in-wallet solution.

[github12101]

Amazing.

Question: how I configure datadir location when running from AppImage, or deb? in Nexus-Qt it's easy, --datadir switch, but here I am not sure.

[l8nit3tr0ubl3]

Try changing it in the home/pioruns/.config/Nexus Wallet/settings.json file, this will run ut at start when the core is started I believe. There should already be an option pointing to .Nexus

[github12101]

settings.json contains only:

{
  "windowX": 456,
  "windowY": 170,
  "windowWidth": 1022,
  "windowHeight": 713,
  "acceptedAgreement": true
}

~/.Nexus folder gets created as well, database is here, along with wallet.dat, nexus.conf. I have no chance to change it?

$ ./nexus_wallet-Linux-1.1.0.AppImage --datadir=/home/pioruns/Nexus1
19:26:19.312 › File server listening on port 9331!
19:26:19.809 › Checking if core binary exists: /tmp/.mount_nexus_lGsX0N/resources/assets/linux/cores/nexus-linux-x64
19:26:19.810 › Core binary exists
19:26:19.810 › nexus.conf exists. Importing username and password.
19:26:19.811 › Core Parameters: -daemon,-avatar,-server,-rpcthreads=4,-fastsync,-datadir=/home/pioruns/.Nexus,-rpcport=9336,-verbose=0,-stake=1
19:26:19.811 › Core Manager: Starting core
19:26:19.819 › Core Manager: Core has started (process id: 2907)
pos 462 201

--datadir=/home/pioruns/Nexus1 this is being ignored, and
Core Parameters: -daemon,-avatar,-server,-rpcthreads=4,-fastsync,-datadir=/home/pioruns/.Nexus,-rpcport=9336,-verbose=0,-stake=1 This is being chosen on my behalf.

[github12101]

I can confirm, when both folders ~/.Nexus and ~/.config/Nexus Wallet not exist, it's stuck on "Connecting to Nexus Core..."

[github12101]

Another error:
While bootstrapping recent Database, in the background, Nexus Core is still downloading blocks from zero, wasting CPU and bandwidth resources! I am bootstrapping while I am syncing O_o.
Downloaded 6% of database, while Core synced 4436 blocks from 1 peer.
CPU thread is saturated 100% by nexus_wallet, when it should do NOTHING, just wait for download to complete.

[github12101]

795 MB of RAM taken to do nothing, just downloading file in the background while I waste CPU and bandwidth to download blocks from 1 peer. Electron "efficiency" in usage of resources, bravo.

[github12101]

OK I downloaded whole bootstrap, 3.83GB. Now it's stuck on Downloading the database... 100%.
In the background, Core continues to sync blocks relentlessly, 35k blocks synced.

I can only click Abort bootstrapping, nothing else is happening.

[l8nit3tr0ubl3]

This is a separate issue, and should definitely be opened as a feature request here. You make a solid point but it's not quite a bug as it's working as expected. Just something that could be optimized :) I will add it to my list of things to attempt for the team.
As for "stuck at 100%" it's currently extracting the database into the correct folder.... as you say 3.83 GB worth. Once finished it will automatically restart the core and you'll continue syncing the remaining blocks normally, although it should say "extracting database" or something to inform the user of this process.

UPDATE
I think I may have a simple fix for both of your new issues, I will be testing in a few minutes, please create an issue request for each and I will answer each separately with a solution :)

tl;dr for anyone with this issue use:
sudo sysctl kernel.unprivileged_userns_clone=1 to bypass this error.

[github12101]

I thought so! So I left it for an hour, just came back and it's done! I am 65k blocks behind, not far:)

# systemctl kernel.unprivileged_userns_clone=1
Unknown operation kernel.unprivileged_userns_clone=1.

This doesn't work on Debian, and Debian uses systemd.
And sysctl command requires installation of separate package - procps. So you can add to your tl;dr:
#apt update && apt install procps
if sysctl returns command not found.

[github12101]

As for "stuck at 100%" it's currently extracting the database into the correct folder.... as you say 3.83 GB worth. Once finished it will automatically restart the core and you'll continue syncing the remaining blocks normally, although it should say "extracting database" or something to inform the user of this process.

Upon finished downloading there should be a message - unpacking! Must be added, as this process can take as long as downloading did.
And core must be stopped while bootstrap is being downloaded.

Right now, I can see from terminal, core has been stopped and restarted again to accept bootstrap, my guess when zip file has been already unpacked. It should be stopped when downloading is started, not when file is unpacked.

$ ./nexus_wallet-Linux-1.1.0.AppImage
19:30:26.559 › File server listening on port 9331!
19:30:27.001 › Checking if core binary exists: /tmp/.mount_nexus_iVvcYZ/resources/assets/linux/cores/nexus-linux-x64
19:30:27.002 › Core binary exists
19:30:27.002 › nexus.conf exists. Importing username and password.
19:30:27.002 › Core Parameters: -daemon,-avatar,-server,-rpcthreads=4,-fastsync,-datadir=/home/pioruns/.Nexus,-rpcport=9336,-verbose=0,-stake=1
19:30:27.003 › Core Manager: Starting core
19:30:27.010 › Core Manager: Core has started (process id: 3324)
pos 462 201
20:30:24.524 › Core Manager: Stop function called
20:30:27.768 › Core Manager: Core still running after stop command for: 0 seconds, CorePID: 3331
20:30:28.800 › Core Manager: Core still running after stop command for: 1 seconds, CorePID: 3331
20:30:29.828 › Core Manager: Core still running after stop command for: 2 seconds, CorePID: 3331
20:30:30.868 › Core Manager: Core still running after stop command for: 3 seconds, CorePID: 3331
20:30:31.900 › Core Manager: Core still running after stop command for: 4 seconds, CorePID: 3331
20:30:33.010 › Core Manager: Core stopped gracefully.
20:30:34.613 › Checking if core binary exists: /tmp/.mount_nexus_iVvcYZ/resources/assets/linux/cores/nexus-linux-x64
20:30:34.613 › Core binary exists
20:30:34.613 › nexus.conf exists. Importing username and password.
20:30:34.740 › Core Parameters: -daemon,-avatar,-server,-rpcthreads=4,-fastsync,-datadir=/home/pioruns/.Nexus,-rpcport=9336,-verbose=0,-stake=1
20:30:34.740 › Core Manager: Starting core
20:30:34.769 › Core Manager: Core has started (process id: 3530)

[KenCorma]

I will be making a document that will outline some FAQs etc about different versions of linux and such tomorrow.

[KenCorma]

Also I sent a build to @pioruns that does not contain gnomekeyring

[KenCorma]

https://github.com/Nexusoft/NexusInterface/blob/master/docs/Linux-FAQ.md

[github12101]

This is fixed in nexus_wallet-Linux-1.2.0.AppImage:

./nexus_wallet-Linux-1.2.0.AppImage 
12:49:46.807 › File server listening on port 9331!
12:49:47.122 › Checking if core binary exists: /tmp/.mount_nexus_1ZRkgt/resources/assets/linux/cores/nexus-linux-x64
12:49:47.123 › Core binary exists
12:49:47.123 › Core Manager: Data Directory path not found. Creating folder: /home/pioruns/.Nexus
12:49:47.123 › Core Parameters: -daemon,-server,-rpcthreads=4,-fastsync,-datadir=/home/pioruns/.Nexus,-rpcport=9336,-verbose=0,-stake=1
12:49:47.123 › Core Manager: Starting core
12:49:47.133 › Core Manager: Core has started (process id: 5728)
12:50:16.697 › Core Manager: Stop function called
12:50:17.491 › Core Manager: Core still running after stop command for: 0 seconds, CorePID: 5735
12:50:18.510 › Core Manager: Core still running after stop command for: 1 seconds, CorePID: 5735
12:50:19.537 › Core Manager: Core still running after stop command for: 2 seconds, CorePID: 5735
12:50:20.562 › Core Manager: Core still running after stop command for: 3 seconds, CorePID: 5735
12:50:21.578 › Core Manager: Core still running after stop command for: 4 seconds, CorePID: 5735
12:50:22.594 › Core Manager: Core still running after stop command for: 5 seconds, CorePID: 5735
12:50:23.606 › Core Manager: Core still running after stop command for: 6 seconds, CorePID: 5735
12:50:24.619 › Core Manager: Core still running after stop command for: 7 seconds, CorePID: 5735
12:50:25.630 › Core Manager: Core stopped gracefully.

Wallet goes to UI without any problems, starts bootstrapping, problem with Sandbox is gone for AppImage, tested on Debian Buster 10 (MATE env.).

[KenCorma]

I am going to close this now. But feel free to open this back up if this same issue is back.