Den här tråden bytte ämne med tiden. Den började som en installationsguide för CasaOS BTOP från 2024, men blev betydligt mer värdefull i mars 2025 när ZimaOS 1.3.3 lade till en inbyggd btop-panel för prestandaövervakning och flera ZimaBoard-/ZimaBlade-användare upptäckte att den nya binärfilen kraschade med Ogiltig instruktion (kärndump skapad).
Den slutliga diagnosen kom från IceWhale, inte från spekulationer i communityn: Zima-Giorgio sade att teamet inte hade tagit hänsyn till ZimaBoard-processorn när de kompilerade btop och att problemet skulle åtgärdas i ZimaOS 1.4.0. Detta innebär att det rör sig om ett historiskt CPU-kompatibilitetsfel med en tydlig versionsgräns.
ZimaOS 1.3.3 introducerade den inbyggda btop-panelen
IceWhales versionsinformation för 1.3.3 introducerade btop som en ny panel för prestandaövervakning i ZimaOS-instrumentpanelen. Målet var att ge användarna insyn i CPU-, minnes-, process- och systemaktivitet utan att de behövde installera en separat övervakningsstack.
Använd versionsgränsen för ZimaOS 1.3.3 när du läser källtråden.
Genvägen på instrumentpanelen öppnade en skärm för återanslutning
På de berörda systemen öppnade ett klick på genvägen en tillfällig port med högt portnummer och visade endast en uppmaning om att återansluta.
Att köra btop direkt gav en ogiltig instruktion
Den viktigaste diagnostiska raden var:
btop
Ogiltig instruktion (kärndump skapad)Det meddelandet betyder att processorn försökte köra en instruktion som binärfilen hade byggts för att använda, men som maskinvaran inte stödde. Detta skiljer sig helt från en webbläsarcache eller en WebSocket-timeout.
Flera webbläsare uteslöt ett webbläsarspecifikt fel
Användare testade Firefox, Chrome/Chromium, Safari, Brave, Opera och Edge, i vanliga fönster och privata/inkognitofönster. Beteendet förblev detsamma.
Denna negativa testning var användbar eftersom IceWhales första felsökningsfråga var om problemet kunde vara webbläsarspecifikt.
DevTools visade WebSocket-fel efter att backend slutat fungera
Berörda användare hade Intel Celeron N3450-generationen
En användare av ZimaBoard 832 och en användare av ZimaBlade jämförde maskinvaran och lade märke till att de hade Intel Celeron N3450-processorer av samma klass. De frågade om btop-binären hade kompilerats för en nyare ZimaCube-instruktionsuppsättning.
Den hypotesen bekräftades senare av IceWhale.
IceWhale bekräftade att kompileringsmålet var fel
Den 27 mars skrev Zima-Giorgio att problemet hade lokaliserats och skulle lösas i ZimaOS 1.4.0, eftersom den ursprungliga btop-versionen inte tog hänsyn till ZimaBoard-processorn.
Detta är den starkaste slutsatsen från källorna och bör ersätta spekulativa åtgärder som att installera om webbläsare eller manuellt installera en annan btop-binär på den oföränderliga ZimaOS-värden.
Den ändrade höga porten var avsiktlig
CorrectRoadH från IceWhale sade att btop öppnades på en annan hög port varje gång som en säkerhetsfunktion, avsedd att göra den tillfälliga övervakningssessionen svårare att återanvända direkt.
Den ändrade porten var därför inte i sig ett tecken på felet.
Diagnostisera inte aktuella btop utifrån 1.3.3-felet
Aktuella ZimaOS ligger långt bortom 1.3.3/1.4.0. Om btop inte fungerar i dag bör du dokumentera den aktuella ZimaOS-versionen, CPU-modellen, det exakta terminalfelet och om det bara är genvägen i instrumentpanelen eller även CLI:t som påverkas.
En Ogiltig instruktion på ett modernt bygge kan fortfarande tyda på CPU-inkompatibilitet, men det bör undersökas som en ny regression i stället för att antas bero på det gamla paketet från 2025.
Varför WebSocket-felet uppstod efter CPU-felet
Instrumentpanelen startar en interaktiv terminalsession av btop-typ. Om btop-processen omedelbart avslutas med en ogiltig CPU-instruktion förlorar frontend den backend den förväntar sig att kommunicera med. Meddelanden om stängd WebSocket-anslutning och nekad anslutning kan därför vara sekundära effekter av den kraschade processen.
Det här är en användbar generell felsökningslärdom: det första felet i webbläsarens konsol är inte alltid grundorsaken. Jämför det med vad som händer när det underliggande kommandot körs direkt.
Att även genvägen till Nätverkshanteraren slutade fungera gav ytterligare en ledtråd
En drabbad användare sa att både genvägarna till Resurshanteraren och Nätverkshanteraren gav samma återanslutningsbeteende, medan den vanliga webbterminalen fungerade. Det tydde på att felet var knutet till miljön för verktyget som startades via genvägen, snarare än till ett fullständigt avbrott i ttyd.
IceWhale behövde fortfarande det direkta btop kraschen och informationen om delad N3450-maskinvara för att identifiera det faktiska problemet med kompileringsmålet.
Att installera om samma 1.3.3-version skulle inte ändra CPU-instruktionerna
När IceWhale bekräftade att själva binärfilen hade kompilerats utan hänsyn till ZimaBoard-processorn kunde ominstallation av webbläsare, rensning av cacheminnet och ominstallation av samma systemversion inte korrigera den körbara filens instruktionsuppsättning.
Den varaktiga lösningen krävde en nykompilerad binärfil som levererades i nästa ZimaOS-version.
Maskinvarukompatibilitet omfattar binärfiler i användarutrymmet, inte bara kärndrivrutiner
Kompatibilitetsdiskussioner fokuserar ofta på nätverks-, grafik- eller lagringsdrivrutiner. Den här incidenten visar att även ett generiskt x86-operativsystem kan sluta fungera på äldre processorer om ett medföljande program kompileras med instruktioner som maskinvaran inte stöder.
För x86-maskiner från tredje part gäller en Ogiltig instruktion meddelandet är därför värdefulla bevis och bör inkluderas ordagrant i en supportrapport.
Vanliga frågor om btop-kompatibilitet
Orsakades källproblemet av Firefox eller Chrome?
Nej. Användare återskapade problemet i många webbläsare och privata lägen.
Vad sa IceWhale att grundorsaken var?
btop-binärfilen hade kompilerats utan hänsyn till ZimaBoards CPU-instruktionsuppsättning.
Vilken version skulle åtgärda det?
Zima-Giorgio sa att den korrigerade btop skulle komma i ZimaOS 1.4.0.
