These issues do not appear to be hardware related.
After we release a beta 3 it would be helpful if you could update to that and if it still locks up, send in your logs mentioning the rough time of the lockup in the email.
Ok, I'll send the logs. Is there an ETA for the ReadyNAS 6.2.3 beta 3?
With ReadyNAS 6.2.3-T1652 beta 2 it has been 8 hours and still no lock up. I'm starting to copy stuff.
The upgrade to 6.2 is a one way upgrade and upgrades to e.g. Cloud functionality, snapshots are one way. If downgrading was possible it would require a factory reset.
Identifying what is causing issues for a small number of users and fixing those in a firmware update or providing advice based on the logs as to what is causing the issue is the best way forward.
Downgrading is not possible. Anyway even if it were it would only be a temporary fix as you would lose bug fixes and other improvements from 6.2.x. What we want is to get to the bottom of why your units are hanging and resolve this.
Mine lasted about 3 days after installing the beta before locking up... guess that's some kind of improvement 😛 It only took a couple of hours before it froze when running 6.2.0->2.
Yeah are backup that runs is a large amount of little files as well (1.7TB)and it appears to lock up during that backup every time since going to 6.2.* Has to major bug in 6.2 since same backup ran fine for a year in 6.1.*
Same here - RN316 running 6.1.x for about a year for Shadow Protect backups, upgraded to 6.2 and locks up every few days. No antivirus, no snapshots, no apps
Same here - RN104 was running great all last year on 6.1.5, I was worried about updating to latest firmware and kept ignoring the update notice (obviously my gut feeling about not wanting to update was correct) I wish I didn't hit the stupid update firmware notice! Now my unit keep locking up after half a day or more of being on. Obviously an issue with 6.2.x as I downgraded to 6.2.0 but with no luck. Also sounds like Netgear don't know what is going on and are blaming it on the Hard Drives. I am running WD 2TB RED NAS Hard Drives in RAID5 so it's not a Seagate issue it's the FIRMWARE!!!!
I looked at your logs dickerj and your disks looked fine. However some user's systems may be locking up due to disk issues so it is a good thing for users to check.
I have downgraded to 6.2.0 from 6.2.2 and it did lock up once, since then it has stayed on running and this will be it's second night in a row but I'm not holding my breath
Ok Diary day # 2, Netgear ReadyNAS 104 still running on firmware 6.2.0 Amazing! Not sure how long this will hold up for but I will keep my backup schedule running as per normal and hope for the best.
Well, came to this thread to report the very 1st freeze/lockup on my RN 516 running 6.2.2 and 6 x 4 TB WD Red drives. The box was executing a back up task - from an old WD My Book 1 TB USB2 drive. Very slow! Left it to run overnight.
In the morning it had locked up. The browser based front-end/GUI was unresponsive, but the machine could be pinged. I tried to switch off the NAS using the front panel button. The display showed "shutting down' but after 10-15 minutes of waiting I was forced to use the switch on the back panel to completely power down and then restart the NAS.
There are no log entries that would give me a clue why the box locked up. I was worried about data corruption but all seems ok. I may want to downgrade to 6.2 if this happens again.
Diary day # 3, Netgear ReadyNAS 104 still running on firmware 6.2.0 and is still responsive with successful backups from last night and is finishing some to the USB Drive now. Will keep you posted.
We have a fix for premature snipping of logs so if your NAS locks up again a fresh set of logs may be more useful. If you send a fresh set of logs it would be helpful if you could state the rough time of the crash.
Those of you with x86_64 devices may also wish to consider 6.3.3 beta 3:
We have a fix for premature snipping of logs so if your NAS locks up again a fresh set of logs may be more useful. If you send a fresh set of logs it would be helpful if you could state the rough time of the crash.
Conclusion of 6.2.3-T1652 5 days trial: After the initial 33 hours, the RN10400 has locked 2 to 3 times a day, but the editing of etc/sysctl.conf with "kernel.panic = 1" and "kernel.panic_on_oops = 1" is working great. There for, I'm considering ReadyNAS 6.2.3-T1652 with kernel options a temporary workaround.
Staring ReadyNAS 6.2.3-T1672 (beta 3) trial and I'll try to send you the logs after the first lockup...
First lockup happened around 6:10 PM and I've sent the logs. Mdgm, do you also want the logs?
System was locked up (T1652), so rebooted at ~9PM to upload new FW Rebooted again to start new FW Copied ~225GB from NAS to local storage, finished ~3:42AM System was discovered locked up ~5:12AM Rebooted ~5:48 AM Logs gathered, sent in.
It appears most/all of you have USB devices attached to your systems. Can you try removing them and see if the crash still occurs?
It would also be great if you could connect via SSH and run `journalctl -af` until the system crashes. It's quite possible that we'd get some useful output that wouldn't make it to disk.
I am willing to try out beta software and hope there are no more crashes/freezes.
mdgm - Yes, the NAS box has been running without a problem for about 17-18 hours, with no USB drive connected. Drive spin down is enabled and inactivity counter set at 45 minutes. Snapshots are created every 24 hours. So far so good. I intend keeping the box powered on with 6.2.2. for at least another 12-24 hours to check before attempting to flash the beta.
It appears most/all of you have USB devices attached to your systems. Can you try removing them and see if the crash still occurs?
It would also be great if you could connect via SSH and run `journalctl -af` until the system crashes. It's quite possible that we'd get some useful output that wouldn't make it to disk.
By "USB devices" are you also including UPS data cables? Because I only bought my UPS after the lockups started, to eliminate possible power spikes.
Anyway, I'm running 'journalctl -af' with the UPS data cable plugged in until next lockup. After that, I'll disconnect the UPS and repeat the process.
