常见问题
在有些时候运行 OOMOL Studio 可能会遇到一些问题,下面是一些常见问题的排查和处理方法。
无法启动 OOMOL Studio
如果你是 Windows 用户,请确保你的操作系统大于等于 Windows 19044(Windows 21H2) 版本,这是因为 OOMOL Studio 在 Windows 系统中使用了 WSL2
作为虚拟机的基座。而低于这个版本的 Windows 系统有时遇到 WSL2 无法正常启动的问题。
而如果是 macOS 用户,请确保你的操作系统大于等于 13.1(Ventura) 版本,这是因为 OOMOL Studio 在 macOS (Intel) 系统中使用了 Virtualization.framework
,而低于这个版本的 macOS 系统缺失了一些必要的 API,会导致 OOMOL Studio 无法正常启动。
出现 The OOMOL Studio must be single instance
警告
由于目前 OOMOL Studio 暂不支持多实例启动,因此如果你尝试启动多个实例,就会弹出这个警告窗口。
如果你认为你没有启动另一个实例,那可能是进程残留所导致的,你可以在任务管理器中结束其他实例的进程,然后重新打开 OOMOL Studio。
出现 The OOMOL Studio is running under ARM64 translation mode. Please download the ARM64 architecture version.
警告
这个警告是因为目前 OOMOL Studio 暂时不支持在 Apple Silicon 的 ARM64 架构下运行 x86_64 架构的 OOMOL Studio,因此你需要重新下载并安装 ARM64 架构版本的 OOMOL Studio。
无法在 OOMOL Studio 中下载依赖、安装插件等
当你遇到这种情况时,极大的概率是由于网络问题所导致的。因为像 npm、pip、系统源大多数都是在国外的服务器上,所以可能会无法连接。
你可以尝试以下几种方法来解决这个问题:
- 打开 OOMOL Studio -> 设置 -> 偏好设置 -> 中国镜像源 -> 启用
- 确保当前的系统时间是准确的,当差异较大时,可能会导致 SSL 证书验证失败
如果上面两种方法都无法解决问题的话,你可以尝试打开代理软件,并需要开启下面的选项:
- 如果是 Windows 系统,并使用了类似
Clash
等代理软件,请确保开启了:- 允许局域网访问(Allow LAN)
- TUN 模式(TUN Mode),并使用
GVisor
堆栈 - 服务模式(Service Mode)
- 如果是 macOS 系统,并使用了类似
Surge
等代理软件,请确保开启了:- 允许局域网访问
- 增强模式(Enhanced Mode)
如果是 Windows 用户,且以上方法都无效的话,可能是遇到了 Windows 本身的问题,建议你尝试以下方法:
打开终端(管理员模式),然后执行以下命令:
wsl --shutdown
netsh winsock reset
netsh int ip reset all
netsh winhttp reset proxy
ipconfig /flushdns
然后重启计算机,再次尝试打开 OOMOL Studio。
除了以上方法,你还可以尝试: 关闭防火墙、退出杀毒软件,亦或者手动搜索: WSL2 无法联网
,来获取更多的解决方案。
Docker Desktop for Windows 报错 wsl distro proxy in ovm-oomol-stuio distro has exited with an error: exit status 1
OOMOL Studio 会创建一个名为 ovm-oomol-studio
的 WSL2 发行版,并在其中运行 OOMOL Studio 的虚拟机。
而 Docker Desktop for Windows 在有些时候会为 WSL2 中的发行版进行自动集成。
当 OOMOL Studio 退出时,我们也会让 ovm-oomol-studio
发行版关机,此时 Docker Desktop for Windows 发现集成的 WSL2 发行版已经退出,就会报出这个错误。
解决方案为: 打开 Docker Desktop for Windows 的设置,进入 Resources
-> WSL Integration
,然后取消勾选 ovm-oomol-studio
发行版 -> 点击 Apply & restart
按钮即可。
如果以上的解决方案依旧无法解决问题,可以尝试下面的办法:
- 使用
wsl --set-default <发行版名称>
命令将其他 Linux 发行版设置为 WSL 默认发行版。(设置完成后,需要重启 Docker Desktop for Windows) - 关闭 Docker Desktop for Windows 的
WSL Integration
功能。 - 关闭 Docker Desktop for Windows 的
Resource Saver
功能。
关于此问题的更多信息,请参阅: https://github.com/docker/for-win/issues/14187
Docker Desktop for Windows 除了上面的错误外,还有可能会抛出下面的错误(解决方案一致):
configuring docker in ovm-oomol-studio: docker cli config: failed to write file: exit status Oxffffffff
running wsl distro proxy in ovm-oomol-stuio distro: exit status 1
打开的项目中的小脚本区块的依赖无法安装
用户在打开了一个社区项目后,发现其中的流使用了小脚本,在运行时却发现小脚本区块依赖的模块找不到。


假设开发者们在流的小脚本区块中依赖了第三方模块,这种情况下,如果是 Node.js 代码会使用 package.json
文件,如果是 Python 代码会使用 requirements.txt
或者之类的其他文件来锁定第三方模块的版本。
那么当用户将流克隆到本地(锁定模块版本的文件一定也被克隆,否则无法保证代码一定可以执行)并开始使用后,如果开发者此时更新了依赖模块的版本,用户也要同步更新只有两种选择:
-
删掉本地的项目,重新拉取开发者最新的项目然后安装所有的东西,再运行。
-
查看开发者的改动,自己在本地进行同样的操作。
这两种选择对于用户都是很繁琐的,尤其是对于不懂代码的用户来说。
另一种情况,用户也许会将包作为基础进行二次开发,那么当用户在某些代码上用到的模块与原包的模块有了版本冲突,将会无法处理。
因此我们选择禁止开发者们在发布到线上的流中使用依赖了第三方模块的小脚本区块。
我们建议在发布前将所有小脚本区块转换为共享区块,这样就可以避免上述问题。
如果你一定要使用小脚本区块,那么请记住你只能使用代码语言内置的模块。
我们将会在未来的版本中解决这个问题
如何在 OOMOL Studio 内部连用户计算机上的服务(MySQL、Redis 等)
OOMOL Studio 应用内是一个容器环境,它与用户的计算机是相互隔离的。
但是你可以通过容器提供的特殊域名 host.docker.internal
访问计算机上的服务。
参考 Docker 容器连接宿主机服务。
例如:
你在计算机上启动了一个 Mysql 服务,在本机上可以通过 http://127.0.0.1:3306
连接,在 OOMOL Studio 内你可以通过 http://host.docker.internal:3306
连接。
获取日志
当遇到其他问题时,你可以尝试获取 OOMOL Studio 的日志来帮助我们定位问题。
目前 OOMOL Studio 的日志分别存放在以下位置:
- Windows:
%USERPROFILE%\.oomol-studio\logs
和%USERPROFILE%\.oomol-studio\ovm\log
- macOS:
~/.oomol-studio/logs
和~/.oomol-studio/ovm-krun/logs
(如果你是 Intel 架构的 Mac,则是~/.oomol-studio/ovm/logs
)
请不要在互联网上公开你的日志文件,因为它们可能包含敏感信息。
在线求助
如果你在使用 OOMOL Studio 的过程中遇到问题,或者有任何建议和意见,请随时通过 community 与我们联系。