Repository navigation
minsky hangs with Wait... Resetting: 100% #1006
Description
After a fresh "apt update" and "apt upgrade" of
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.5 LTS (Noble Numbat)"
I installed minsky 3.29.1-1 from
https://software.opensuse.org/download.html?project=home%3Ahpcoder1&package=minsky
Using
echo 'deb http://download.opensuse.org/repositories/home:/hpcoder1/xUbuntu_24.04/ /' | sudo tee /etc/apt/sources.list.d/home:hpcoder1.list
curl -fsSL https://download.opensuse.org/repositories/home:hpcoder1/xUbuntu_24.04/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/home_hpcoder1.gpg > /dev/null
sudo apt update
sudo apt install minsky
Result: successfull minsky install, free of error.
$ which minsky
/bin/minsky
If I try
$ minsky
[30916:0928/075056.605023:FATAL:content/browser/zygote_host/zygote_host_impl_linux.cc:128] No usable sandbox! If you are running on Ubuntu 23.10+ or another Linux distro that has disabled unprivileged user namespaces with AppArmor, see https://chromium.googlesource.com/chromium/src/+/main/docs/security/apparmor-userns-restrictions.md. Otherwise see https://chromium.googlesource.com/chromium/src/+/main/docs/linux/suid_sandbox_development.md for more information on developing with the (older) SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
Trace/breakpoint trap (core dumped)
I followed
https://chromium.googlesource.com/chromium/src/+/main/docs/security/apparmor-userns-restrictions.md
using Option 3 (safest) but it made no difference to the problem at hand.
The following website no-longer exists
https://chromium.googlesource.com/chromium/src/+/main/docs/linux/suid_sandbox_development.md
Google 503. That’s an error. That’s all we know.
So I lived dangerously!
I then execute the following command WITHOUT a Ravel model
$ minsky --no-sandbox
BadWindow (invalid Window parameter)BadWindow (invalid Window parameter)BadDrawable (invalid Pixmap or Window parameter)BadDrawable (invalid Pixmap or Window parameter)BadWindow (invalid Window parameter)BadWindow (invalid Window parameter)BadDrawable (invalid Pixmap or Window parameter)BadWindow (invalid Window parameter)BadDrawable (invalid Pixmap or Window parameter)BadWindow (invalid Window parameter)BadWindow (invalid Window parameter)BadGC (invalid GC parameter)BadWindow (invalid Window parameter)BadWindow (invalid Window parameter)BadWindow (invalid Window parameter)BadWindow (invalid Window parameter)BadDrawable (invalid Pixmap or Window parameter)BadDrawable (invalid Pixmap or Window parameter)BadWindow (invalid Window parameter)BadWindow (invalid Window parameter)
The minsky app opens and hangs with a message box appearing as attached.
When I "quit" minsky it does not return control to the terminal.
Further information.
$ which minsky-RESTService
/bin/minsky-RESTService
and when minsky is running
ps ax | grep minsky-RESTService
shows no rest service is running?
p.s. purging the rest service
sudo apt-get purge minsky-restservice
and reinstllaing minsky does not make any difference.
Activity
highperformancecoder commentedon Sep 28, 2026
This looks like the same sandbox madness mentioned in. However /usr/lib/minsky/chrome-sandbox no longer exists, so the workaround of changing its permissions won't work. I'll need to noodle this out with Claude's support.
It would be interesting to see if Ubuntu 26.04 has the exact same problem, or if this is an issue affecting just the 24.04 release.
bugfix: try disable-gpu to see if it solves GH #1006
highperformancecoder commentedon Sep 29, 2026
I have updated the install script to explicitly include chrome-sandbox. It still doesn't have the suid bit set, so you have to explicitly set that with chmod u+s /usr/lib/minsky/chrome-sandbox.
One other thing I've noticed is that Minsky doesn't display a GUI on Ubuntu 24.04 and 26.04. It is unclear whether to lay the blame at the feet of VirtualBox (I'm running a virtual instance), Ubuntu (due to increased security, including sandbox requirements), Wayland (since Minsky is fundamentally an X11 application) or Electron. However, Minsky now accepts and passes through long flags to the underlying Electron engine, so I got it to work by passing the flag --ozone-platform=x11 to the minsky command. The same effect could be achieved by logging into your Ubuntu system via ssh (ssh -X localhost).
So there's two workarounds that need to be applied here. Possibly the --ozone-platform flag is only required on a Virtual instance, and everything's fine on physical hardware.
ggborg commentedon Sep 29, 2026
Working with
sudo chmod u+s /usr/lib/minsky/chrome-sandbox;/bin/minsky --ozone-platform=x11'
on ubuntu 24.04. Thank you !
ggborg commentedon Sep 29, 2026