NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
rn104 updated to 6.4.0 and possible solution to random lock-ups
Hello everyone,
I have updated my RN104 last week, and have been poised by the unit hanging up randomly since then.
I have searched andread a lot of posts here, and after 5 hard reboot and re-syncing, I may have found a solution.
At least, it's been 1 day the unit has not locked up, so I'm crossing my fingers.
The culprit, I think, might by the snapshot creation.
I had 3 share protected by snapshots. Documents, Caldav/Carddav hosting and my ebooks collection.
All those share had a daily snapshooting policy.
After reading the "FAQs on upgrading ReadyNAS firmware to 6.4.0" post linked in here, the last chapter caught my eye:
btrfs-cleaner is commonly invoked after Smart Snapshot Management prunes older snapshots. ReadyNAS commonly prunes older snapshots based on its snapshot schedule.
Now, my nas is almost 80% full, and the snapshots where taking around 4Gb of space (out of a 4 disks Raid5 array of 6To usable).
As the unit completely locks up, no SSH-ing in to check how much CPU the btrfs-cleaner process takes, of course, and nothing in the syslog appart a bunch "@" at the time the hangs-up hapenned.
Oct 13 21:48:05 nas kernel: [ 6591.520831] md: delaying resync of md126 until md127 has finished (they share one or more physical units) Oct 13 21:48:06 nas readydropd[4685]: DEBUG:readydropd.c:897 Shares.conf has been changed Oct 13 21:48:07 nas readydropd[4685]: DEBUG:readydropd.c:652 Reload Share configs Oct 13 21:48:08 nas kernel: [ 6593.661751] md: delaying resync of md126 until md127 has finished (they share one or more physical units) Oct 13 21:48:08 nas kernel: [ 6594.415415] md: delaying resync of md126 until md127 has finished (they share one or more physical units) Oct 13 21:48:09 nas kernel: [ 6594.927980] md: delaying resync of md126 until md127 has finished (they share one or more physical units) @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@Oct 13 21:53:01 nas kernel : imklog 5.8.11, log source = /proc/kmsg started. Oct 13 21:53:01 nas rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="2837" x-info="http://www.rsyslog.com"] start Oct 13 21:53:01 nas kernel: Booting Linux on physical CPU 0x0 Oct 13 21:53:01 nas kernel: Initializing cgroup subsys cpuset Oct 13 21:53:01 nas kernel: Initializing cgroup subsys cpu Oct 13 21:53:01 nas kernel: Initializing cgroup subsys cpuacct
Reading the FAQ, I thought that I would try to remove the snapshots creation schedules of my shares, and remove all the existing snapshots.
Since this moment, I had no more issues.
By the way netgear, I'd really like to know another way than using the timeline to clean old snapshot.
Removing 108 snapshots manually, one after the other was not fun...
The "emergency" button in the shares/browse is nowhere to be found today in my web gui, so that only leaves the timeline afaik...
It might not be relevant, but maybe the combination of low disk space, numerous snapshots and high CPU usage (because syncing back the array after the last hard reboot, my cpu load reported by "top" was around 12~15 at that time) might have been the issue.
To be really torough, I even have deactivated DLNA, AFP and SMB services, leaving only the NFS, as I'm using linux boxes as client anyway.
DLNA re-scanning the shares seems to be heavy, when resyncing the disks.
Maybe it can help other people I've seen here having unresponsive units after bootup too.
I'll come back comenting here if the unit locks-up again, but I am confident.
Regards.
Thierry.
6.4.1 is released. Who is taking the risk? :)
92 Replies
Replies have been turned off for this discussion
6.4.1 Helped with my lock ups but now it's the same with that... so no, 6.4.1. has not fixed the issue
- BrianL, i'm hesitant to upgrade. I think i was one of the first to go to 6.4.0, and i totally regret that. The downgrade to 6.2.5, and the restore afterwards were a real PITA...
Check https://community.netgear.com/t5/Using-your-ReadyNAS/ReadyNAS-RN104-locks-up-after-upgrade-to-6-4-1/td-p/1017692Hi michaelarnauts,
Using the latest Firmware will let us know (NETGEAR and affected users) if it addresses all the issues encountered on the previous 6.4.0 Firmware. It could also help generate a fix in the next Firmware release if the said issues are still being experienced.
Let me know if you have other questions.
Kind regards,
BrianL
NETGEAR Community Team
I've got a RN104 on 6.4.1RC and it still locks up. I created a seperate thread for my issue because I didn't realize this was such a huge problem. Is this something that everyone is just waiting out? This is my first ReadyNAS product and my first "stable" update issue on any device. Betas sometimes come with unforeseen chaos, but stable release bugs are not normally this severe.
Alternatively, I'm still in the return window for my retailer. Should I swap this unit out for one that is not so issue prone? A quick search of the forum shows a lot of struggle with the 104/102 units over the years. Any advice/input/suggested solutions would be much appreciated.
My thread can be found here: https://community.netgear.com/t5/Using-your-ReadyNAS/RN104-Freezes-when-doing-large-transfers-via-USB-3-0-on-6-4-0/m-p/1009276#M98351
Update: Yesterday's problem appears to be solved. 6.4.1RC didn't fix my issue, and it seems to have fixed everyone else's issues so I started to troubleshoot other possibilities. Last week I rotated in a 10 year old disk and it didn't cause any problems until it caused a LOT of problems all at once, so my mind didn't immediately go to that disk. Apparently it was falling behind the rest of the array and causing the RN104 to lock-up. None of my disks have ever been on the "compatability list" and this has never caused me any isses, but for some reason this old drive doesn't play well with the others. It is similarly spec'd, so I'm guessing that it is experiencing some kind of hardware failure that SMART isn't able to pick up.
My appologies for being so alarmed while my crisis was full-swing, and my thanks to all of you for providing such helpful explainations of your issues and solutions. This allowed me to narrow my issue down without waiting on phone support for 11 more hours.
With four fresh (and matching) disks in play, the 6.4.1RC is working well now and moves tons of data with no lock-up.
Learning2NAS wrote:
...With four fresh (and matching) disks in play, the 6.4.1RC is working well now and moves tons of data with no lock-up.
Great news, thx for the update. If anything changes, please do let us know.
I bought a QNAP NAS today. Bybye Netgear, you screwed it.
Regards,
Peter
- How are your NICs configured? Are they bonded? Try unbonding them if they are. It helped me s little but did not fix the issue. It seemed to have freeze less. I've gone back to 6.2.5 but have left the NICs as standalone and only one is plugged in. I don't have a proper switch to use bonding anyway so no biggie for me.
Only ever been using one NIC here too, simple unmanaged gigabit switch so no point.
Hello,
I encounter the same locks up on my RN104, but from what I saw it happens when writting a lot of data on the NAS.
Unfortunately I followed Netgear support advice and factory resetted.
When backing up from NAS to local HDD via FTP (2.6TB) : all went good.
When trying to put the data back on the NAS via FTP it locked up after 280GB of 200-1200Gb files.
I then factory resetted (to have a clean system without corruption due to "violent" power off) and put it back to support mode because they asked fot it.
No add on activated and fresh RMAed (Support thought it could be hardware malfunction) and fresh intalled from T29 Beta (which was the last to date when I recieved the RMA unit).
I double checked my disks via RN104 integrated test and WD utilities tests => all still perfectly fine even after all the violent power off.
So maybe add-on itself is not the issue but rather the fact that add-on write a lot of data on the system (even temporary data).
This looks a lot like a memory overflow.
Only 1 Gb Network interface used in a IPV4 environnement.
I have only ever been using 1 NIC. So that hasn't been the cause of my problem.
I have had less lock ups since, not running backups, and disabling SABNZB.
Hi,
I have to report that it wasn't the solution.
As long as the nas is left alone, it's fine.
As soon as some activity is done on the disk, it freezes.
It hapenned yesterday when downloading a Linux iso image through transmission.
It hapenned again today, when I was copying a 6Gb file to the nas.
It froze mid-copy.
No reaction to the power button, lcd stays black, nothing happens...
But it does answers to pings.
No way to enter a SSH session though.
Is there a way for someone having only osx and linux machines (ie: no computer running windows) to downgrade the nas to 6.2.5?
It was running perfectly fine until I did the update.
I'm pretty annoyed of this whole update mess, I have to admit.
I wish I did read this forum before...
Hi tripy,
We may have to further investigate this issue that you've been experiencing. Kindly attach the logs so we can have a thorough look at what's going on with your ReadyNAS unit. In copying large or small files, if you will do a direct connection between your ReadyNAS and PC, will it froze or complete the copy? With regard to your downgrade question, I apologize but it won't be possible to go back to 6.2.4 or 6.2.5.
Looking forward to your response.
Kind regards,
BrianL
NETGEAR Community Team
Hello Brian, thanks for the message.
Yes, I did check that article.
In my initial post, when I was refering to "The "emergency" button in the shares/browse is nowhere to be found", I was in fact talking about the recovery mode.
Sorry about that, I had not the article on view at the moment I wrote my post.
As shown in the screenshot, the recovery button (
) is not there.
For the moment, the NAS is still up.
Crossing my fingers it stays that way.
Regards.
Thierry.
I also found that deleting all snapshots fix it for me too.
Here's a script I wrote that did it for me :manhappy:
share=$1 for snapshot in `rn_nml -Q snapshot:/data/$share | grep Snapshot_Name | cut -c30-39` do rn_nml -d snapshot:/data/$share@$snapshot:1 done
Save this into a file and then use by passing the share name as parameter. But please use the above script with caution, you might want to try the commands individually first. It basically queries for all snashots for the given share, cuts out the ID and then deletes them one at a time. Saved my LOTS of time.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
