[Help] F6-424 Max Rebooting Hardware? Software?
Posted: 08 Sep 2026, 07:19
My F6-424 Max has been running fine on TOS 6.x, I upgraded to 7.x and all seemed to be well too.
Intel i5-1235U, 4 x 16TB Drive in RAID 5 + 1TB NVME.
It runs file sharing + Plex and hasn't missed a beat until now.
Last week I did two things
1. I installed immich and shared my 200k photo library (read only) and it was chugging away on that from Friday.
2. On Saturday I picked up some more RAM, a single stick of Lexar LD5DS016G 16GB to go alongside the stock 8GB module until I get some more money and/or RAM prices come down.
It rebooted fine and kept working without issue, happily running Plex the whole time.
On Monday it appears have rebooted itself with a message saying "Device Chesterv has encountered an abnormal shutdown, possibly caused by a power outage or system error. It is recommended to check the device and system status as soon as possible.". It sits behind a dedicated UPS which hasn't reported an outage... so it's at least not mains.
On boot it decided that the Volume was corrupt and seems to have started to automatically rebuild itself. That seemed to (eventually) come good this morning so I figured I'd check things out give it the latest software update it had been asking for, so I downloaded the latest 7.0.1169 did that and it decided it was corrupt again and started Syncronising again, although this time the shared folders started being accessible after only a few %.
I had done a pretty quick and dirty RAM test with stressapptest, this didn't immediately fail, but I figured
None of the services seem to have restarted themselves automatically, but manually enabling Plex seems to get it running again. I haven't started Docker for immich again yet, I figure I'll let the system finish synchronising and see what happens first.
Next steps?
Once it's done synchronising, I figure I remove the extra RAM stick and see if it stays stable. If it reboots itself again before that happens, I will pull the RAM earlier, not sure I want to interrupt the current process otherwise.
Test 1: Longer RAM Test? Maybe memtest instead of the inline stressapptest.
Test 2: Stock 8GB
Test 3: 1 x 16GB Lexar module?
Test 4: Back to this configuration?
Anyone seen anything like this before?
Intel i5-1235U, 4 x 16TB Drive in RAID 5 + 1TB NVME.
It runs file sharing + Plex and hasn't missed a beat until now.
Last week I did two things
1. I installed immich and shared my 200k photo library (read only) and it was chugging away on that from Friday.
2. On Saturday I picked up some more RAM, a single stick of Lexar LD5DS016G 16GB to go alongside the stock 8GB module until I get some more money and/or RAM prices come down.
It rebooted fine and kept working without issue, happily running Plex the whole time.
On Monday it appears have rebooted itself with a message saying "Device Chesterv has encountered an abnormal shutdown, possibly caused by a power outage or system error. It is recommended to check the device and system status as soon as possible.". It sits behind a dedicated UPS which hasn't reported an outage... so it's at least not mains.
On boot it decided that the Volume was corrupt and seems to have started to automatically rebuild itself. That seemed to (eventually) come good this morning so I figured I'd check things out give it the latest software update it had been asking for, so I downloaded the latest 7.0.1169 did that and it decided it was corrupt again and started Syncronising again, although this time the shared folders started being accessible after only a few %.
I had done a pretty quick and dirty RAM test with stressapptest, this didn't immediately fail, but I figured
None of the services seem to have restarted themselves automatically, but manually enabling Plex seems to get it running again. I haven't started Docker for immich again yet, I figure I'll let the system finish synchronising and see what happens first.
Next steps?
Once it's done synchronising, I figure I remove the extra RAM stick and see if it stays stable. If it reboots itself again before that happens, I will pull the RAM earlier, not sure I want to interrupt the current process otherwise.
Test 1: Longer RAM Test? Maybe memtest instead of the inline stressapptest.
Test 2: Stock 8GB
Test 3: 1 x 16GB Lexar module?
Test 4: Back to this configuration?
Anyone seen anything like this before?