A clean installation of ZimaOS v.1.6.2 resulted in a temperature of 75-85°C, ZimaBrain not starting on v.1.6.2

sergii · July 14, 2026, 8:51pm

Something strange is happening:

A clean installation of ZimaOS v.1.6.2 resulted in a temperature of 75-85°C; upon inspection, it was discovered that the disks were constantly being polled.
Installing ZimaBrain on v.1.6.2 resulted in ZimaBrain not starting on v.1.6.2, although everything worked fine in versions 1.6.0 and 1.6.1.
Now in more detail:
After a clean installation of ZimaOS v.1.6.2 on a ZimaBoard2 with RAID 1 enabled, the temperature remained at 75-85°C, even with an additional Noctua fan. I tried installing lm_sensors and other data collection tools, but the results were negative. To figure out what was going on, I decided to install ZimaBrain.
After installing ZimaBrain in Docker, version 1.6.2 returns the “unable to start” message. I rebooted the system—the same result, everything in the settings is fine. How did I get it to start? We installed it via Docker, but didn’t specify port 8601. After installation, we started it, stopped it, then added the port via the settings, and Brian started. “Dancing with a tambourine.”
So far, I’ve restarted ZimaBoard2 three times. The system has calmed down, the temperature has dropped to 32 °C, and the constant disk and fan spikes have stopped.
The AppData, Docker, Gallery, and Downloads folders are freely moveable.
I haven’t installed anything other than ZimaBrain to test the OS, so I haven’t reached any conclusions yet.

sergii · July 15, 2026, 5:18am

ZimaBrain CE Brain Session

Exported: 2026-07-14 20:56:12

1. What needs attention?

Time: 2026-07-14 18:45:38

ZimaBrain Answer

Question asked

What needs attention?

Verification status

@@VERIFY:VERIFIED@@ VERIFIED FROM SAME-REPORT EVIDENCE

This answer is based on evidence found in the current report.
Active layer: Critical Same-Report Verifier
Layer file: app/brain/answer_builder.py

Top verified issues

YELLOW: ZimaOS media mirror path missing
YELLOW: Failed systemd unit detected

Checked but not detected in this report

No failed snapraid-sync.service protection failure was detected in this report.
No SnapRAID data/parity-on-same-physical-disk issue was detected in this report.
No full host /DATA mounted back as /DATA with published ports was detected in this report.
No GPU acceleration failure was detected by the current critical rules.

Critical Same-Report Verifier

YELLOW: ZimaOS media mirror path missing
Evidence: nsenter: reassociate to namespaces failed: Operation not permitted
Why it matters: ZimaOS normally exposes storage through /media, /DATA/.media, and /var/lib/casaos_data/ Missing mirror paths can cause Files app or app path confusion.
Next safest step: Verify ZimaOS local-storage state before treating this as an app problem.
YELLOW: Failed systemd unit detected
Evidence: nsenter: reassociate to namespaces failed: Operation not permitted
Why it matters: A failed host unit can indicate a broken scheduled task, service, or maintenance layer.
Next safest step: Inspect the exact failed unit before changing anything.

Direct answer / severity

This is a global system attention question.
ZimaBrain found same-report verifier findings and listed them above.

What not to touch

Do not run docker system prune.
Do not remove containers in bulk.
Do not delete /media folders until findmnt verifies whether they are active mounts.
Do not change Docker bind mounts until the exact source path is verified.
Do not repair SnapRAID/mergerfs until pool config, parity disk, and data disks are verified.

Next safest step

Review the listed critical findings one by one. Start with the exact evidence shown before changing containers, mounts, disks, or services.

Forum-ready summary

ZimaBrain found same-report verifier findings. Review the listed evidence first and avoid broad repair actions until the exact failed unit, mount, disk, or service is confirmed.

2. Are there Files / AppData / media path problems?

Time: 2026-07-14 18:48:01

ZimaBrain Answer

Question asked

Are there Files / AppData / media path problems?

Verification status

@@VERIFY:PARTIALLY VERIFIED@@ PARTIALLY VERIFIED

Some local evidence was found, but one or more key facts still need confirmation.
Active layer: Files / AppData / Media Same-Report Verifier
Layer file: app/brain/answer_builder.py

Direct answer / severity

YELLOW: ZimaOS media mirror path missing
Evidence: nsenter: reassociate to namespaces failed: Operation not permitted
Why it matters: ZimaOS normally exposes storage through /media, /DATA/.media, and /var/lib/casaos_data/ Missing mirror paths can cause Files app or app path confusion.
Next safest step: Verify ZimaOS local-storage state before treating this as an app problem.

Next safest step

Verify the exact active mount paths with findmnt before deleting /media folders, moving AppData, or editing container bind mounts.

Forum-ready summary

ZimaBrain found same-report Files/AppData/media evidence. Verify active mount paths before changing AppData, Files, or Docker bind paths.

3. Check paths and mounts media

Time: 2026-07-14 18:52:21

ZimaBrain Answer

Question asked

Check paths and mounts media

Verification status

@@VERIFY:NOT VERIFIED@@ GUIDANCE ONLY / NOT VERIFIED FROM CURRENT REPORT

Guidance only. The current report does not contain matching evidence to verify this as a diagnosis.
Active layer: App Runtime Diagnostics Layer
Layer file: app/brain/layers/app_runtime_diag.py

Direct answer / severity

This is an app runtime diagnostic question.
Detected symptom: app runtime issue
No app name was detected from the question.
No matching local container/app evidence was found.

Next safest step

Ask which app is affected, then check container status, logs, bind mounts, and the exact storage path.

Forum-ready summary

The app runtime issue is not verified because the affected app was not identified.

4. Are there failed services?

Time: 2026-07-14 18:54:26

ZimaBrain Answer

Question asked

Are there failed services?

Verification status

@@VERIFY:NOT VERIFIED@@ GUIDANCE ONLY / NOT VERIFIED FROM CURRENT REPORT

Guidance only. The question did not match a verified diagnostic layer, so this is not verified from the current report.
Active layer: Fallback Guidance Route
Layer file: app/brain/answer_builder.py

Direct answer / severity

This Flask cockpit currently answers dashboard evidence questions reliably.
Try: show me dashboard alerts, explain disk CRC errors, why is a filesystem usage alert showing 100%, which containers are exited, which disks are healthy, or is my system protected?

Next safest step

Ask a dashboard-specific question, or extend the Flask verifier with additional ZimaOS layers.

Forum-ready summary

Ask a dashboard-specific question so ZimaBrain can route the answer through the correct verifier layer.

5. What is using CPU?

Time: 2026-07-14 18:58:45

ZimaBrain Answer

Question asked

What is using CPU?

Verification status

@@VERIFY:VERIFIED@@ VERIFIED FROM SAME-REPORT EVIDENCE

This answer is based on evidence found in the current report.
Active layer: Service / Activity Same-Report Verifier
Layer file: app/brain/answer_builder.py

Direct answer / severity

No high CPU process was detected in the current report.
CPU process evidence was checked, but no process matched the high-CPU threshold during this export.

Next safest step

If the CPU load returns, export again while the load is happening and compare the top CPU process evidence.

Forum-ready summary

ZimaBrain checked same-report CPU evidence and did not detect a high-CPU process during this export.

6. Reason for systemd unit failure.

Time: 2026-07-14 19:05:25

ZimaBrain Answer

Question asked

Reason for systemd unit failure.

Verification status

@@VERIFY:NOT VERIFIED@@ GUIDANCE ONLY / NOT VERIFIED FROM CURRENT REPORT

Guidance only. The question did not match a verified diagnostic layer, so this is not verified from the current report.
Active layer: Fallback Guidance Route
Layer file: app/brain/answer_builder.py

Direct answer / severity

This Flask cockpit currently answers dashboard evidence questions reliably.
Try: show me dashboard alerts, explain disk CRC errors, why is a filesystem usage alert showing 100%, which containers are exited, which disks are healthy, or is my system protected?

Next safest step

Ask a dashboard-specific question, or extend the Flask verifier with additional ZimaOS layers.

Forum-ready summary

Ask a dashboard-specific question so ZimaBrain can route the answer through the correct verifier layer.

7. Explain disk CRC errors

Time: 2026-07-14 19:11:02

Question asked

Explain disk CRC errors

Verification status

@@VERIFY:VERIFIED@@ VERIFIED

Active layer: SMART / NVMe Health Layer
Layer file: app/brain/layers/smart_health_layer.py

Direct answer / severity

SMART/NVMe evidence did not show obvious disk failure indicators in the parsed fields.

Critical findings

None parsed.

Warnings / context

None parsed.

Healthy / normal parsed evidence

None parsed.

Next safest step

Collect complete host SMART/NVMe evidence before replacing disks or creating RAID/ZFS:

for d in /dev/sda /dev/sdb /dev/sdc /dev/sdd; do echo "===== SMART $d ====="; smartctl -H -A "$d" 2>&1 | sed -n '1,140p'; done
for n in /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1; do echo "===== NVME $n ====="; nvme smart-log "$n" 2>&1 | sed -n '1,90p'; done

Safe recommendation

Do not call a drive fully healthy from SMART PASSED alone. Check reallocated sectors, pending sectors, offline uncorrectable sectors, CRC errors, NVMe critical warnings, media errors, unsafe shutdowns, and error log entries. If detailed SMART attributes are N/A or missing, treat health as only partially verified. RAID, SAS/HBA, USB bridge, or controller passthrough can hide SMART detail.

Forum-ready summary

SMART/NVMe health should be verified from host evidence. PASSED is useful, but it is not enough by itself. If detailed SMART attributes are unavailable or N/A, treat the result as limited visibility, not confirmed healthy and not confirmed failed. Review critical attributes, controller passthrough, and NVMe error fields before deciding a disk is healthy or safe for RAID/ZFS.

8. Is systemd-networkd-wait-online failed?

Time: 2026-07-14 19:13:59

ZimaBrain Answer

Question asked

Is systemd-networkd-wait-online failed?

Verification status

@@VERIFY:VERIFIED@@ VERIFIED FROM SAME-REPORT EVIDENCE

This answer is based on evidence found in the current report.
Active layer: Service / Activity Same-Report Verifier
Layer file: app/brain/answer_builder.py

Direct answer / severity

No matching service/activity finding was detected in the current report.
The report may still contain raw active service, pidstat, iostat, or process evidence, but no rule matched this exact question yet.

Next safest step

Ask for a fresh export while the issue is happening, then check active services, pidstat/iostat evidence, and failed units together.

Forum-ready summary

No matching same-report service/activity finding was detected for this question. Collect a fresh export while the symptom is active.

9. What is using CPU?

Time: 2026-07-14 19:15:21

ZimaBrain Answer

Question asked

What is using CPU?

Verification status

@@VERIFY:VERIFIED@@ VERIFIED FROM SAME-REPORT EVIDENCE

This answer is based on evidence found in the current report.
Active layer: Service / Activity Same-Report Verifier
Layer file: app/brain/answer_builder.py

Direct answer / severity

No high CPU process was detected in the current report.
CPU process evidence was checked, but no process matched the high-CPU threshold during this export.

Next safest step

If the CPU load returns, export again while the load is happening and compare the top CPU process evidence.

Forum-ready summary

ZimaBrain checked same-report CPU evidence and did not detect a high-CPU process during this export.

gelbuilding · July 15, 2026, 9:25am

Thank you for running ZimaBrain CE and exporting the full session. This is very useful.

The report confirms that ZimaBrain started, but it also exposed several issues in the current diagnostic routing.

The nsenter: reassociate to namespaces failed: Operation not permitted message was incorrectly interpreted as evidence of a missing media mirror path and a failed systemd unit. Those two warnings should therefore not be treated as confirmed ZimaOS problems.

The questions about failed services and the reason for the systemd unit failure also did not reach the correct failed-unit diagnostic layer. In addition, the SMART answer reported a verified result even though no detailed SMART attributes were parsed.

For the CPU question, ZimaBrain did check the available process evidence, but no high-CPU process was active at the exact time of the export. A new export would need to be taken while the temperature and CPU load are high.

Thank you again for testing this. I will use this session to correct the permission-error classification, failed-service routing, and SMART verification status in the next ZimaBrain CE release.

sergii · July 16, 2026, 8:03pm

ZimaBrain CE Brain Session

Exported: 2026-07-16 19:56:23

1. Check Immich container paths and mounts

Are there any failed services?

Time: 2026-07-16 19:40:47

ZimaBrain Answer

Question asked

Check Immich container paths and mounts

Are there any failed services?

Verification status

@@VERIFY:NOT VERIFIED@@ GUIDANCE ONLY / NOT VERIFIED FROM CURRENT REPORT

Guidance only. The current report does not contain matching evidence to verify this as a diagnosis.
Active layer: App Runtime Diagnostics Layer
Layer file: app/brain/layers/app_runtime_diag.py

Direct answer / severity

This is an app runtime diagnostic question.
Detected symptom: app runtime issue
Detected app: immich
immich was not found in the current report.
No matching local container/app evidence was found.

Next safest step

Collect container status and logs for immich before giving repair steps.

Forum-ready summary

The immich issue is not verified because the current report does not contain matching app evidence.

2. What is using CPU?

Time: 2026-07-16 19:41:39

ZimaBrain Answer

Question asked

What is using CPU?

Verification status

@@VERIFY:VERIFIED@@ VERIFIED FROM SAME-REPORT EVIDENCE

This answer is based on evidence found in the current report.
Active layer: Service / Activity Same-Report Verifier
Layer file: app/brain/answer_builder.py

Direct answer / severity

No high CPU process was detected in the current report.
CPU process evidence was checked, but no process matched the high-CPU threshold during this export.

Next safest step

If the CPU load returns, export again while the load is happening and compare the top CPU process evidence.

Forum-ready summary

ZimaBrain checked same-report CPU evidence and did not detect a high-CPU process during this export.

3. Is port 8601 reachable on LAN?

Time: 2026-07-16 19:43:18

ZimaBrain Answer

Question asked

Is port 8601 reachable on LAN?

Verification status

@@VERIFY:PARTIALLY VERIFIED@@ PARTIALLY VERIFIED

Some local evidence was found, but one or more key facts still need confirmation.
Active layer: Network Exposure / Firewall Layer
Layer file: app/brain/layers/network_exposure.py

Direct answer / severity

This is a network exposure / firewall verification question.
The answer comes from the Network Exposure / Firewall Layer using same-report Docker and firewall evidence.

Top exposure risks first

No top exposure risk was detected from the parsed evidence.

Published Docker ports

No published Docker ports were parsed from the current report.

Port reachability self-check

No live port reachability probe evidence was collected.

High-risk exposure checks

No container with full /DATA read-write access and published ports was detected in this report.

Remote access / tunnel indicators

No Cloudflare, Tailscale, proxy, tunnel, or similar remote-access container names were detected from parsed evidence.

ZimaBrain CE self audit

ZimaBrain CE inspected its own container security settings.
nsenter: reassociate to namespaces failed: Operation not permitted

ZFW firewall status

ZFW appears installed from host evidence.
zfw-ui.service: nsenter: reassociate to namespaces failed: Operation not permitted
ZFW is installed/active, but firewall rules do not appear applied yet.
Current evidence suggests DOCKER-USER may still be pass-through until Safe-Apply/Commit is used.

DOCKER-USER firewall chain

DOCKER-USER evidence was collected.
The DOCKER-USER chain contains rules. Review them before assuming Docker ports are blocked.

How to interpret this

A published Docker port only proves Docker has mapped the port; LAN reachability still depends on host firewall, ZFW, router, VLAN, bind rules, and whether the service answers on the host LAN IP.
A tunnel container can expose services externally even when router port-forwarding is not used.
A container with /DATA write access and a published port deserves extra attention.
Do not change firewall rules until the service, port, and access path are confirmed.

Next safest step

Review published ports, reachability results, tunnel/proxy containers, authentication, and firewall restrictions before exposing services further.

Forum-ready summary

Network exposure should be verified from Docker published ports, live localhost/LAN reachability, tunnel/proxy containers, and DOCKER-USER firewall evidence. Do not assume a service is safe just because Docker published a port. Confirm the exact port, service, authentication, bind address, and firewall path before exposing it.

4. Is my firewall blocking this app?

Time: 2026-07-16 19:43:59

ZimaBrain Answer

Question asked

Is my firewall blocking this app?

Verification status

@@VERIFY:PARTIALLY VERIFIED@@ PARTIALLY VERIFIED

Some local evidence was found, but one or more key facts still need confirmation.
Active layer: Network Exposure / Firewall Layer
Layer file: app/brain/layers/network_exposure.py

Direct answer / severity

This is a network exposure / firewall verification question.
The answer comes from the Network Exposure / Firewall Layer using same-report Docker and firewall evidence.

Top exposure risks first

No top exposure risk was detected from the parsed evidence.

Published Docker ports

No published Docker ports were parsed from the current report.

Port reachability self-check

No live port reachability probe evidence was collected.

High-risk exposure checks

No container with full /DATA read-write access and published ports was detected in this report.

Remote access / tunnel indicators

No Cloudflare, Tailscale, proxy, tunnel, or similar remote-access container names were detected from parsed evidence.

ZimaBrain CE self audit

ZimaBrain CE inspected its own container security settings.
nsenter: reassociate to namespaces failed: Operation not permitted

ZFW firewall status

ZFW appears installed from host evidence.
zfw-ui.service: nsenter: reassociate to namespaces failed: Operation not permitted
ZFW is installed/active, but firewall rules do not appear applied yet.
Current evidence suggests DOCKER-USER may still be pass-through until Safe-Apply/Commit is used.

DOCKER-USER firewall chain

DOCKER-USER evidence was collected.
The DOCKER-USER chain contains rules. Review them before assuming Docker ports are blocked.

How to interpret this

A published Docker port only proves Docker has mapped the port; LAN reachability still depends on host firewall, ZFW, router, VLAN, bind rules, and whether the service answers on the host LAN IP.
A tunnel container can expose services externally even when router port-forwarding is not used.
A container with /DATA write access and a published port deserves extra attention.
Do not change firewall rules until the service, port, and access path are confirmed.

Next safest step

Review published ports, reachability results, tunnel/proxy containers, authentication, and firewall restrictions before exposing services further.

Forum-ready summary

Network exposure should be verified from Docker published ports, live localhost/LAN reachability, tunnel/proxy containers, and DOCKER-USER firewall evidence. Do not assume a service is safe just because Docker published a port. Confirm the exact port, service, authentication, bind address, and firewall path before exposing it.

5. Which apps have exposed ports?

Time: 2026-07-16 19:44:38

ZimaBrain Answer

Question asked

Which apps have exposed ports?

Verification status

@@VERIFY:PARTIALLY VERIFIED@@ PARTIALLY VERIFIED

Some local evidence was found, but one or more key facts still need confirmation.
Active layer: Network Exposure / Firewall Layer
Layer file: app/brain/layers/network_exposure.py

Direct answer / severity

This is a network exposure / firewall verification question.
The answer comes from the Network Exposure / Firewall Layer using same-report Docker and firewall evidence.

Top exposure risks first

No top exposure risk was detected from the parsed evidence.

Published Docker ports

No published Docker ports were parsed from the current report.

Port reachability self-check

No live port reachability probe evidence was collected.

High-risk exposure checks

No container with full /DATA read-write access and published ports was detected in this report.

Remote access / tunnel indicators

No Cloudflare, Tailscale, proxy, tunnel, or similar remote-access container names were detected from parsed evidence.

ZimaBrain CE self audit

ZimaBrain CE inspected its own container security settings.
nsenter: reassociate to namespaces failed: Operation not permitted

ZFW firewall status

ZFW appears installed from host evidence.
zfw-ui.service: nsenter: reassociate to namespaces failed: Operation not permitted
ZFW is installed/active, but firewall rules do not appear applied yet.
Current evidence suggests DOCKER-USER may still be pass-through until Safe-Apply/Commit is used.

DOCKER-USER firewall chain

DOCKER-USER evidence was collected.
The DOCKER-USER chain contains rules. Review them before assuming Docker ports are blocked.

How to interpret this

A published Docker port only proves Docker has mapped the port; LAN reachability still depends on host firewall, ZFW, router, VLAN, bind rules, and whether the service answers on the host LAN IP.
A tunnel container can expose services externally even when router port-forwarding is not used.
A container with /DATA write access and a published port deserves extra attention.
Do not change firewall rules until the service, port, and access path are confirmed.

Next safest step

Review published ports, reachability results, tunnel/proxy containers, authentication, and firewall restrictions before exposing services further.

Forum-ready summary

Network exposure should be verified from Docker published ports, live localhost/LAN reachability, tunnel/proxy containers, and DOCKER-USER firewall evidence. Do not assume a service is safe just because Docker published a port. Confirm the exact port, service, authentication, bind address, and firewall path before exposing it.

6. what needs attention

Time: 2026-07-16 19:51:16

ZimaBrain Answer

Question asked

what needs attention

Verification status

@@VERIFY:VERIFIED@@ VERIFIED FROM SAME-REPORT EVIDENCE

This answer is based on evidence found in the current report.
Active layer: Critical Same-Report Verifier
Layer file: app/brain/answer_builder.py

Top verified issues

YELLOW: ZimaOS media mirror path missing
YELLOW: Failed systemd unit detected

Checked but not detected in this report

No failed snapraid-sync.service protection failure was detected in this report.
No SnapRAID data/parity-on-same-physical-disk issue was detected in this report.
No full host /DATA mounted back as /DATA with published ports was detected in this report.
No GPU acceleration failure was detected by the current critical rules.

Critical Same-Report Verifier

YELLOW: ZimaOS media mirror path missing
Evidence: nsenter: reassociate to namespaces failed: Operation not permitted
Why it matters: ZimaOS normally exposes storage through /media, /DATA/.media, and /var/lib/casaos_data/.media. Missing mirror paths can cause Files app or app path confusion.
Next safest step: Verify ZimaOS local-storage state before treating this as an app problem.
YELLOW: Failed systemd unit detected
Evidence: nsenter: reassociate to namespaces failed: Operation not permitted
Why it matters: A failed host unit can indicate a broken scheduled task, service, or maintenance layer.
Next safest step: Inspect the exact failed unit before changing anything.

Direct answer / severity

This is a global system attention question.
ZimaBrain found same-report verifier findings and listed them above.

What not to touch

Do not run docker system prune.
Do not remove containers in bulk.
Do not delete /media folders until findmnt verifies whether they are active mounts.
Do not change Docker bind mounts until the exact source path is verified.
Do not repair SnapRAID/mergerfs until pool config, parity disk, and data disks are verified.

Next safest step

Review the listed critical findings one by one. Start with the exact evidence shown before changing containers, mounts, disks, or services.

Forum-ready summary

ZimaBrain found same-report verifier findings. Review the listed evidence first and avoid broad repair actions until the exact failed unit, mount, disk, or service is confirmed.

7. Check the systemd unit

Time: 2026-07-16 19:53:15

ZimaBrain Answer

Question asked

Check the systemd unit

Verification status

@@VERIFY:NOT VERIFIED@@ GUIDANCE ONLY / NOT VERIFIED FROM CURRENT REPORT

Guidance only. The question did not match a verified diagnostic layer, so this is not verified from the current report.
Active layer: Fallback Guidance Route
Layer file: app/brain/answer_builder.py

Direct answer / severity

This Flask cockpit currently answers dashboard evidence questions reliably.
Try: show me dashboard alerts, explain disk CRC errors, why is a filesystem usage alert showing 100%, which containers are exited, which disks are healthy, or is my system protected?

Next safest step

Ask a dashboard-specific question, or extend the Flask verifier with additional ZimaOS layers.

Forum-ready summary

Ask a dashboard-specific question so ZimaBrain can route the answer through the correct verifier layer.

8. Are there Files / AppData / media path problems?

Time: 2026-07-16 19:55:07

ZimaBrain Answer

Question asked

Are there Files / AppData / media path problems?

Verification status

@@VERIFY:PARTIALLY VERIFIED@@ PARTIALLY VERIFIED

Some local evidence was found, but one or more key facts still need confirmation.
Active layer: Files / AppData / Media Same-Report Verifier
Layer file: app/brain/answer_builder.py

Direct answer / severity

YELLOW: ZimaOS media mirror path missing
Evidence: nsenter: reassociate to namespaces failed: Operation not permitted
Why it matters: ZimaOS normally exposes storage through /media, /DATA/.media, and /var/lib/casaos_data/.media. Missing mirror paths can cause Files app or app path confusion.
Next safest step: Verify ZimaOS local-storage state before treating this as an app problem.

Next safest step

Verify the exact active mount paths with findmnt before deleting /media folders, moving AppData, or editing container bind mounts.

Forum-ready summary

ZimaBrain found same-report Files/AppData/media evidence. Verify active mount paths before changing AppData, Files, or Docker bind paths.

gelbuilding · July 18, 2026, 2:35am

Thanks, Sergii. This screenshot confirms the ZimaBoard 2 is not idle.

The CPU is at 83°C with approximately 54% total utilisation, all four cores are continuously around 50–58%, and the processor is running at 3.1 GHz. This explains the high temperature, but we still need to identify which process or service is creating the sustained load.

Interestingly, the ZimaBrain export said no high-CPU process was detected. This means the activity may have been missed during its sampling period, or the current detection threshold needs adjusting. I will include this in the ZimaBrain improvements.

While the load is visible, please run:

ps -eo pid,ppid,comm,args,%cpu,%mem --sort=-%cpu | head -20

Then run:

top -b -d 2 -n 5 -o %CPU

Please post the complete outputs. This should identify whether the activity comes from RAID synchronisation, disk management, a ZimaOS service, or another process.

sergii · July 18, 2026, 5:46am

Unfortunately, I wasn’t able to maintain this system temperature for two days. I feel sorry for my new hard drives, as no one will compensate me for their loss. If IceWhaleTech had allocated drives for experiments, I could have continued experimenting. After six hours, I turned off the power. After several reboots, the temperature dropped to 41°C. But, as far as I understand, the system errors remain. But I’ll try again.

sergii · July 18, 2026, 6:37pm