NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
ReadyNAS RN214 check root fs - booting 47% - stalled
round I have a RN214 runninfg V6.10.2 (downgraded from V6.10.3 a month or 2 ago). I had to unplug the unit after it became un-responsive (again) but this time, instead of rebooting normally, it ...
If the NAS is used, then Netgear won't provide paid support. readynasd is the Netgear NAS application itself.
Have you tried booting up the NAS read-only? Probably worth doing before you try going into tech support mode.
Though if this isn't critical, I'd suggest just doing a factory default and rebuilding the NAS.
SandsharkI am looking preferably for instructions on how to repair/replace the main filesystem so I can fix it myself if it ever happens again.
I bought that NAS used so I have no formal support. I would have to check how much Netgear charges for looking into this and fixing it (assuming they charge only if the repair of the main filesystem is sucessful)...
I have seen posts from members of this community fixing similar problems so that is an option too...
What is the purpose of readynasd? Is there supposed to be more than 1 active at any given time?
Thanks
If the NAS is used, then Netgear won't provide paid support. readynasd is the Netgear NAS application itself.
Have you tried booting up the NAS read-only? Probably worth doing before you try going into tech support mode.
Though if this isn't critical, I'd suggest just doing a factory default and rebuilding the NAS.
StephenB I just tried booting in RO mode and it did boot. I can access the NAS with the /data partition in RO. I got the few filles that I needed from it...
I looked as the log; the last entry was "starting Balance"... I was running balance as the NAS started with 2 disk, then after it was getting full, a third disk was added, and then, after it was getting full again, the 4th disk was added.
I'm not thrilled about doing factory default and re-buiding the NAS as I will lose snapshots of files but, considering the problems I had recently, it's likely what I need to do...
What do I need to save before doing the factory reset other than the obvious (userids, groups, shares)? And, going forward, what should I check/backup to improve problem determination/likelyhood of fix/keeping the NAS Healthy? When should I update the OS to the latest (6.10.3)?
Do you recomend running a memory test and a disk test before doing the factory reset?
Thanks
Chapi wrote:
I'm not thrilled about doing factory default and re-buiding the NAS as I will lose snapshots of files but, considering the problems I had recently, it's likely what I need to do...
It is a nuisance for sure.
Chapi wrote:
What do I need to save before doing the factory reset other than the obvious (userids, groups, shares)?
Do you recomend running a memory test and a disk test before doing the factory reset?
I think you should look at the log zip file next - checking for disk errors and btrfs errors. disk-info.log, kernel.log and system.log would be good to check. If you see disk issues, then of course you need to deal with them. I wouldn't run a memory test.
You can save the configuration and then restore it after the reset. However, that might not get all settings, so it is useful to document what you have. Screen shots on the various pages is one way. Also, make sure you reinstall any apps before you restore the configuration.
Chapi wrote:
And, going forward, what should I check/backup to improve problem determination/likelyhood of fix/keeping the NAS Healthy? When should I update the OS to the latest (6.10.3)?
On the first question, I do recommend running the maintenance functions on a regularly schedule. Personally I run each every three months (on a staggered schedule). Also, download the log zip files every couple of months and take a look at the disk smart stats in disk-info.log. Of course don't let the volume got more than about 80% full.
Also, I don't recommend using smart snapshots. I suggest custom snapshots, with retention explicitly set. Smart snapshots have indefinite retention, and eventually will fill the volume.
On the update question - no real advice there. I currently am running 6.10.3 (current stable release) and have had no issues with it. But staying with the long term stable release is reasonable too.
StephenB wrote:
Chapi wrote:I'm not thrilled about doing factory default and re-buiding the NAS as I will lose snapshots of files but, considering the problems I had recently, it's likely what I need to do...
It is a nuisance for sure.
Chapi wrote:What do I need to save before doing the factory reset other than the obvious (userids, groups, shares)?
Do you recomend running a memory test and a disk test before doing the factory reset?
I think you should look at the log zip file next - checking for disk errors and btrfs errors. disk-info.log, kernel.log and system.log would be good to check. If you see disk issues, then of course you need to deal with them. I wouldn't run a memory test.
disk-info.log:
Health Data looks good; the only "curious" thing is that one disk (the newest with 11141 power on hours (POH)) shows 2 commands timeouts. The secod newest disk (13588 POH) shows 1 command timeout. The 2 oldest disks (16181 POH) shows 0 commands timeout.
Kernel.log:
A few days before the balance, is saw these errors:
Jun 10 21:16:05 RN4 kernel: BTRFS info (device md127): qgroup_rescan_init failed with -115
Jun 10 21:17:11 RN4 kernel: BTRFS info (device md127): qgroup_rescan_init failed with -115
Jun 10 23:51:41 RN4 kernel: BTRFS info (device md127): qgroup scan completed (inconsistency flag cleared)
Jun 12 12:35:52 RN4 kernel: BTRFS info (device md127): qgroup scan completed (inconsistency flag cleared)After balance was started I saw these:
Jun 16 21:52:03 RN4 kernel: BTRFS info (device md127): relocating block group 17222848217088 flags data
Jun 16 21:52:16 RN4 kernel: BTRFS info (device md127): found 31 extents
Jun 16 21:52:23 RN4 kernel: BTRFS info (device md127): found 31 extents
Jun 16 21:52:23 RN4 kernel: BTRFS info (device md127): relocating block group 17206742089728 flags data
Jun 16 21:52:30 RN4 kernel: BTRFS info (device md127): found 28 extents
Jun 16 21:52:33 RN4 kernel: BTRFS info (device md127): found 28 extents
Jun 16 21:52:33 RN4 kernel: BTRFS info (device md127): relocating block group 17159497449472 flags data
Jun 16 21:52:39 RN4 kernel: BTRFS info (device md127): found 27 extents
Jun 16 21:52:42 RN4 kernel: BTRFS info (device md127): found 27 extents
Jun 16 21:52:42 RN4 kernel: BTRFS info (device md127): relocating block group 17158423707648 flags data
Jun 16 21:52:43 RN4 kernel: BTRFS info (device md127): found 2 extents
Jun 16 21:52:46 RN4 kernel: BTRFS info (device md127): found 2 extents
Jun 16 21:52:46 RN4 kernel: BTRFS info (device md127): relocating block group 17157349965824 flags data
Jun 16 21:52:55 RN4 kernel: BTRFS info (device md127): found 18 extents
Jun 16 21:52:57 RN4 kernel: BTRFS info (device md127): found 18 extents
Jun 16 21:52:57 RN4 kernel: BTRFS info (device md127): relocating block group 17150907514880 flags data
Jun 16 21:52:57 RN4 kernel: BTRFS info (device md127): relocating block group 17149833773056 flags data
Jun 16 21:52:59 RN4 kernel: BTRFS info (device md127): found 4 extents
Jun 16 21:53:01 RN4 kernel: BTRFS info (device md127): found 4 extents
Jun 16 21:53:01 RN4 kernel: BTRFS info (device md127): relocating block group 17128358936576 flags data
Jun 16 21:53:03 RN4 kernel: BTRFS info (device md127): found 7 extents
Jun 16 21:53:05 RN4 kernel: BTRFS info (device md127): found 7 extents
Jun 16 21:53:06 RN4 kernel: BTRFS info (device md127): relocating block group 17127285194752 flags data
Jun 16 21:53:06 RN4 kernel: BTRFS info (device md127): relocating block group 17126211452928 flags data
Jun 16 21:53:06 RN4 kernel: BTRFS info (device md127): relocating block group 17125137711104 flags data
Jun 16 21:53:07 RN4 kernel: BTRFS info (device md127): found 1 extents
Jun 16 21:53:09 RN4 kernel: BTRFS info (device md127): found 1 extents
Jun 16 21:53:09 RN4 kernel: BTRFS info (device md127): relocating block group 17124063969280 flags data
Jun 16 21:53:16 RN4 kernel: BTRFS info (device md127): found 31 extents
Jun 16 21:53:19 RN4 kernel: BTRFS info (device md127): found 31 extents
Jun 16 21:53:19 RN4 kernel: BTRFS info (device md127): relocating block group 17122990227456 flags data
Jun 16 21:53:19 RN4 kernel: BTRFS info (device md127): relocating block group 17121916485632 flags data
Jun 16 21:53:19 RN4 kernel: BTRFS info (device md127): found 1 extents
Jun 16 21:53:21 RN4 kernel: BTRFS info (device md127): found 1 extents
Jun 16 21:53:22 RN4 kernel: BTRFS info (device md127): relocating block group 17120842743808 flags data
Jun 16 21:53:22 RN4 kernel: BTRFS info (device md127): relocating block group 17119769001984 flags data
Jun 16 21:53:22 RN4 kernel: BTRFS info (device md127): relocating block group 17118695260160 flags data
Jun 16 21:53:22 RN4 kernel: BTRFS info (device md127): relocating block group 17117621518336 flags data
Jun 16 21:53:22 RN4 kernel: BTRFS info (device md127): relocating block group 16986625015808 flags data
Jun 16 21:53:28 RN4 kernel: BTRFS info (device md127): found 22 extents
Jun 16 21:53:31 RN4 kernel: BTRFS info (device md127): found 22 extents
Jun 16 21:53:32 RN4 kernel: BTRFS info (device md127): relocating block group 16985551273984 flags data
Jun 16 21:53:33 RN4 kernel: BTRFS info (device md127): found 13 extents
Jun 16 21:53:36 RN4 kernel: BTRFS info (device md127): found 13 extents
Jun 16 21:53:36 RN4 kernel: BTRFS info (device md127): relocating block group 16984477532160 flags data
Jun 16 21:53:39 RN4 kernel: BTRFS info (device md127): found 6 extents
Jun 16 21:53:42 RN4 kernel: BTRFS info (device md127): found 6 extents
Jun 16 21:53:42 RN4 kernel: BTRFS info (device md127): relocating block group 16981256306688 flags data
Jun 16 21:53:43 RN4 kernel: BTRFS info (device md127): found 3 extents
Jun 16 21:53:45 RN4 kernel: BTRFS info (device md127): found 3 extents
Jun 16 21:53:45 RN4 kernel: BTRFS info (device md127): relocating block group 16978035081216 flags data
Jun 16 21:53:47 RN4 kernel: BTRFS info (device md127): found 4 extents
Jun 16 21:53:49 RN4 kernel: BTRFS info (device md127): found 4 extents
Jun 16 21:53:49 RN4 kernel: BTRFS info (device md127): relocating block group 16974813855744 flags data
Jun 16 21:53:52 RN4 kernel: BTRFS info (device md127): found 9 extents
Jun 16 21:53:54 RN4 kernel: BTRFS info (device md127): found 9 extents
Jun 16 21:53:55 RN4 kernel: BTRFS info (device md127): relocating block group 16969445146624 flags data
Jun 16 21:54:01 RN4 kernel: BTRFS info (device md127): found 30 extents
Jun 16 21:54:03 RN4 kernel: BTRFS info (device md127): found 30 extents
Jun 16 21:54:03 RN4 kernel: BTRFS info (device md127): relocating block group 16966223921152 flags data
Jun 16 21:54:10 RN4 kernel: BTRFS info (device md127): found 33 extents
Jun 16 21:54:13 RN4 kernel: BTRFS info (device md127): found 33 extents
Jun 16 21:54:13 RN4 kernel: BTRFS info (device md127): relocating block group 14499838951424 flags metadata|dup
Jun 16 22:39:27 RN4 kernel: apache2 invoked oom-killer: gfp_mask=0x26000c0, order=0, oom_score_adj=0
Jun 16 22:39:27 RN4 kernel: apache2 cpuset=/ mems_allowed=0
Jun 16 22:39:27 RN4 kernel: CPU: 2 PID: 10435 Comm: apache2 Tainted: P O4.4.184.alpine.1 #1
and the NAS looked up around Jun 16 23:52:36 after many oom-killer messages
System.log: shows many of these on the same day:
Jun 14 18:44:05 RN4 snapperd[24243]: special btrfs cmpDirs
Jun 14 18:44:06 RN4 snapperd[24243]: btrfs_read_and_process_send_stream failed
Jun 14 18:44:06 RN4 snapperd[24243]: THROW: btrfs send/receive error
Jun 14 18:44:06 RN4 snapperd[24243]: special btrfs cmpDirs failed, btrfs send/receive error
Jun 14 19:04:20 RN4 snapperd[24243]: special btrfs cmpDirs
Jun 14 19:04:21 RN4 snapperd[24243]: btrfs_read_and_process_send_stream failed
Jun 14 19:04:21 RN4 snapperd[24243]: THROW: btrfs send/receive error
Jun 14 19:04:21 RN4 snapperd[24243]: special btrfs cmpDirs failed, btrfs send/receive error
Jun 21 17:10:20 RN4 readynasd[2056]: Failed to set BTRFS_IOC_SET_DEV_TYPE to /dev/md/data-0:3:0: 30I interpret the above as meaning that the disks are good but that I have btrfs errors that require a factory reset of the NAS to be safe
You can save the configuration and then restore it after the reset. However, that might not get all settings, so it is useful to document what you have. Screen shots on the various pages is one way. Also, make sure you reinstall any apps before you restore the configuration.
Chapi wrote:And, going forward, what should I check/backup to improve problem determination/likelyhood of fix/keeping the NAS Healthy? When should I update the OS to the latest (6.10.3)?
On the first question, I do recommend running the maintenance functions on a regularly schedule. Personally I run each every three months (on a staggered schedule). Also, download the log zip files every couple of months and take a look at the disk smart stats in disk-info.log. Of course don't let the volume got more than about 80% full.
So run balance, scrub and defragment every 3 months or so. From reading this community, doens't defragment cause snapshots to potentially use more space?
Also, I don't recommend using smart snapshots. I suggest custom snapshots, with retention explicitly set. Smart snapshots have indefinite retention, and eventually will fill the volume.
Thanks for the advice
On the update question - no real advice there. I currently am running 6.10.3 (current stable release) and have had no issues with it. But staying with the long term stable release is reasonable too.
0 Links
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
