First Distinguish a Full Host Lock from a Network Failure
The reported machine lost network access, ping, containers, local console response, and video output. That scope is wider than an SMB, Docker, or NIC outage and is consistent with a complete host lockup that requires a power cycle.
If a server disappears remotely, check the local console and display before buying a replacement NIC. A responsive console routes the investigation toward networking; a frozen console and lost display move it toward the kernel, firmware, power, storage, or hardware.
Record the exact event time and whether the machine rebooted itself or remained powered but unresponsive. Those observations determine which previous-boot window and external monitoring data can be compared.
Collect Previous-Boot Evidence Before Changing Variables
The useful first collection in the topic was journalctl -b -1, including kernel and high-priority messages from the boot that ended in the freeze. The ZimaOS team later requested the last 500 previous-boot entries and the persistent journal for private review.
Review logs for personal information before posting them publicly. In this case, persistent journaling was enabled, but the log stopped abruptly at the observed failure time without a panic, OOM kill, GPU reset, storage error, thermal event, watchdog lockup, or normal shutdown.
An empty final record does not prove that nothing failed. It shows that the host stopped before the available local logging path recorded a cause. Repeating the same log command after every identical silent lock adds little unless the capture method changes.
The GPU and Frigate Tests Did Not Identify a Fix
The system used Intel i915 graphics and Frigate VAAPI, so the author first disabled GPU acceleration. The host still froze. Fully stopping Frigate produced a longer interval at one point, but later testing did not establish Frigate as the cause.
The author also tried disabling i915, which made other workloads unusable, and the system eventually crashed again. That result rules out “disable i915” as a successful repair for this case.
The comparison with OpenMediaVault was meaningful: the same hardware and Frigate configuration had been stable there. It raises suspicion about a ZimaOS-specific kernel or driver interaction, but it does not by itself identify which component failed.
IOMMU, VFIO, and SATA LPM Suggestions Were Ruled Out as Fixes
ZimaOS initially included intel_iommu=on and vfio_iommu_type1.allow_unsafe_interrupts=1. A team member asked the author to remove both. The active command line confirmed their absence, yet the machine locked again.
The author then tested libata.force=nolpm because the data disks used an M.2-to-SATA adapter. Another freeze followed the next morning. The thread therefore does not support either boot-parameter change as a fix.
These tests also show why updates can invalidate an experiment: one update had overwritten the customized command-line file. Always verify the active boot command line before interpreting uptime, and change one variable through the established crash window.
Persistent Journal, pstore, and Remote Forwarding Reached Their Limits
The kernel included pstore and hard/soft lockup detection, and the NMI watchdog was active. However, /sys/fs/pstore remained empty after crashes, while no crash kernel was reserved for kdump.
Boot-time netconsole parsed its configuration but started before eth0 existed and disabled itself. A userspace journalctl-to-UDP forwarder reached a second Linux machine, yet it also stopped without a final cause when the host froze.
That outcome is useful: userspace forwarding cannot send messages after the scheduler or network stack stops, and it cannot manufacture a kernel warning that was never emitted. At this point a vendor debug kernel or targeted instrumentation is more valuable than another identical userspace capture.
ZimaOS 1.7.1 Changed Suspected Components but Was Not Yet Validated
A second user on ZimaBoard 2 reported repeated Python and other process crashes near a lockup. The ZimaOS team said it removed the Crudini dependency from zimaos-welcome, reduced that service's resource-request frequency, and planned the changes for a test release.
The team later clarified that the Crudini problem was only a trigger and that the actual system-crash cause was still under investigation. In ZimaOS 1.7.1, it also rolled back the Docker Engine version to improve container startup and reduce the likelihood of DBus broker message blocking.
The final post asks whether another user is stable on 1.7.1; it does not provide the required uptime result. Do not describe 1.7.1 as a confirmed lockup fix until the original failure condition remains stable beyond its previous window.
Escalate with the Tests Already Ruled Out
A strong support package includes hardware model, ZimaOS and kernel versions, storage controller, workloads, crash times, active boot parameters, prior-boot logs, and a list of controlled tests with outcomes.
Explicitly state that GPU acceleration, Frigate isolation, removal of IOMMU/VFIO parameters, i915 disabling, SATA LPM changes, persistent logs, pstore, and remote userspace logging did not produce a confirmed repair in this source case.
If another operating system remains stable under the same workload while ZimaOS continues to lock, preserve that comparison and request a targeted build or vendor investigation. When reliability is operationally critical, returning to the stable environment is a valid stop boundary rather than endlessly stacking unverified parameters.
FAQ
Did Frigate or Intel VAAPI cause the ZimaOS crashes?
The thread did not prove that. Crashes continued after GPU acceleration was disabled and after further i915 isolation tests.
Did removing IOMMU and VFIO parameters fix the lockups?
No. The active command line confirmed both were removed, and the host locked again.
Does ZimaOS 1.7.1 fix full-system freezes?
The release changed Crudini, zimaos-welcome, Docker Engine, and DBus-related behavior, but the topic ends before a stability result confirms recovery.
