I’ve been testing ZimaOS on some older hardware and ran into an interesting failure today that I thought was worth sharing.
ZimaOS v1.7.1, Linux kernel v6.18.9
The original system was built around an older AMD A6 platform. After running for a while, the host became unreachable over the network. When I connected a monitor directly, the console was filled with kernel messages. After rebooting and pulling the previous boot logs through SSH, I found repeated SATA communication failures on the system drive, including link drops, hard resets, failed commands, and the SATA link eventually being reduced from 3.0 Gbps to 1.5 Gbps.
At first I suspected the drive itself, but this was actually the second drive I had seen behave similarly on this particular motherboard. The previous drive was attached to a different SATA port and had also shown intermittent link drops and speed degradation. The current drive had also recently completed a read test successfully.
Because of that, I currently suspect the underlying hardware — motherboard SATA controller, cabling, power delivery, or something else specific to that platform — rather than ZimaOS itself. I’m continuing to monitor it, though, because what makes the situation interesting is that I haven’t previously seen this motherboard exhibit this kind of repeated SATA link behavior while running Windows or other Linux distributions.
What impressed me during all of this was the recovery and diagnostic experience.
I was able to SSH into ZimaOS, use journalctl and SMART data to investigate the previous boot, export the diagnostic logs to text files, SCP them directly to my development desktop, and inspect the failure in detail. That made troubleshooting considerably easier than I expected.
I ultimately decided to move the entire installation to a Dell Optiplex with an Intel i5. I moved the existing ZimaOS system drive along with my 1 TB and 1.5 TB data drives into the Dell and booted it without reinstalling anything.
To my surprise, the migration was basically seamless. ZimaOS booted normally, detected the new motherboard and storage controller, found all of the drives, brought the existing filesystems and services back online, and even came back up using the same network configuration despite the completely different NIC.
So while I’m still watching the SATA issue to determine whether anything ZimaOS-specific contributed to exposing it, the overall experience has been really positive so far. The UI has been great to work with, the underlying Linux system remains accessible enough for proper diagnostics, and being able to transplant the entire installation onto different hardware without rebuilding everything was a very pleasant surprise.
I’ll keep monitoring the new host and update this if the SATA errors return.