This thread changed topics over time. It began as a 2024 CasaOS BTOP installation tutorial, then became much more valuable in March 2025 when ZimaOS 1.3.3 added a built-in btop performance panel and several ZimaBoard/ZimaBlade users discovered that the new binary crashed with Illegal instruction (core dumped).
The final diagnosis came from IceWhale, not community speculation: Zima-Giorgio said the team had not accounted for the ZimaBoard CPU when compiling btop and that the problem would be fixed in ZimaOS 1.4.0. That makes this a historical CPU-compatibility bug with a clear version boundary.
ZimaOS 1.3.3 Introduced the Built-In btop Panel
IceWhale's 1.3.3 release notes introduced btop as a new performance monitoring panel in the ZimaOS dashboard. The goal was to expose CPU, memory, process, and system activity without requiring users to install a separate monitoring stack.
Use the ZimaOS 1.3.3 feature boundary when reading the source thread.
The Dashboard Shortcut Opened a Reconnect Screen
On the affected systems, clicking the shortcut opened a high-numbered temporary port and displayed only a reconnect prompt.
Running btop Directly Produced Illegal Instruction
The key diagnostic line was:
btop
Illegal instruction (core dumped)That message means the CPU attempted to execute an instruction the binary was built to use but the hardware did not support. This is very different from a browser cache or WebSocket timeout.
Multiple Browsers Ruled Out a Browser-Specific Bug
Users tested Firefox, Chrome/Chromium, Safari, Brave, Opera, Edge, normal windows, and private/incognito modes. The behavior remained the same.
That negative testing was useful because the first IceWhale troubleshooting question was whether the issue might be browser-specific.
DevTools Showed WebSocket Failure After the Backend Died
Affected Users Shared the Intel Celeron N3450 Generation
One ZimaBoard 832 user and one ZimaBlade user compared hardware and noticed they shared Intel Celeron N3450-class CPUs. They asked whether the btop binary had been compiled for a newer ZimaCube CPU instruction set.
That hypothesis was later confirmed by IceWhale.
IceWhale Confirmed the Compile Target Was Wrong
On March 27, Zima-Giorgio wrote that the problem had been located and would be solved in ZimaOS 1.4.0 because the original btop build did not take the ZimaBoard CPU into account.
This is the strongest source conclusion and should replace speculative fixes such as reinstalling browsers or manually installing another btop binary onto the immutable ZimaOS host.
The Changing High Port Was Intentional
CorrectRoadH from IceWhale said that btop opening on a different high port each time was a security feature intended to make the temporary monitoring session harder to reuse directly.
The changing port was therefore not itself evidence of the failure.
Do Not Diagnose Current btop from the 1.3.3 Bug Alone
Current ZimaOS is far beyond 1.3.3/1.4.0. If btop fails today, record the current ZimaOS version, CPU model, exact terminal error, and whether the dashboard shortcut or only the CLI is affected.
An Illegal instruction on a modern build could still indicate CPU compatibility, but it should be investigated as a new regression rather than assumed to be the old 2025 package.
Why the WebSocket Error Appeared After the CPU Error
The dashboard launches an interactive terminal-style session for btop. If the btop process immediately dies with an illegal CPU instruction, the frontend loses the backend it expects to communicate with. WebSocket close and connection-refused messages can therefore be secondary effects of the crashed process.
This is a useful general troubleshooting lesson: the first browser-console error is not always the root cause. Compare it with what happens when the underlying command is executed directly.
The Network Manager Shortcut Failing Too Added Another Clue
One affected user said both the Resource Manager and Network Manager shortcuts produced the same reconnect behavior, while the ordinary web terminal itself worked. That suggested the failure was tied to the shortcut-launched tool environment rather than a complete ttyd outage.
IceWhale still needed the direct btop crash and shared N3450 hardware information to identify the actual compile-target problem.
Reinstalling the Same 1.3.3 Build Would Not Change the CPU Instructions
Once IceWhale confirmed the binary itself was compiled without accounting for the ZimaBoard CPU, browser reinstalls, cache clearing, and reinstalling the same system version could not correct the executable's instruction set.
The durable fix required a newly compiled binary delivered in the next ZimaOS release.
Hardware Compatibility Includes User-Space Binaries, Not Only Kernel Drivers
Compatibility discussions often focus on NIC, GPU, or storage drivers. This incident shows that a generic x86 operating system can also break on older CPUs if a bundled application is compiled with instructions that hardware does not implement.
For third-party x86 machines, an Illegal instruction message is therefore valuable evidence and should be included verbatim in a support report.
btop Compatibility FAQ
Was the source problem caused by Firefox or Chrome?
No. Users reproduced it across many browsers and private modes.
What did IceWhale say the root cause was?
The btop binary had been compiled without accounting for the ZimaBoard CPU instruction set.
Which version was supposed to fix it?
Zima-Giorgio said the corrected btop would arrive in ZimaOS 1.4.0.
