This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
I am encountering issues with my Readynas NV+ as it does not boot anymore. When launching it, the "checking quotas" phase ends up well but the booting phase cannot. I can stop the Nas with the button but when it stops, the screen does not (always written "booting...").
When using RaidAr, the device can be detected until the last booting phase but states that the 4 disks are ok. I tried to boot with 3 disks (removing only one and reinstalling the lastly removed each time) but had the same result.
My assumption is that the volume is full and cannot boot well. But I don't know how to resolve that...
Fixing a full OS partition requires tech support mode. Are you comfortable/familar with linux shell commands? IF not, try paid Netgear support (my.netgear.com) and ask for "per incident" support.
You'd boot up in tech support mode, and then mount the OS partition.
After that, you'd check the fullness, and (assuming it is full) resolve it by truncating logs and clearing the cache. If you can mount the C volume, then it is also possible to move folders of any add-ons you installed to the C volume, and replace the original with a sym link.
Now I am able to enter commands (ls, cd, mount...). I saw that I had to enter "start_raid.sh" for starting the raid volume to work : I did it. The problem is that I don't know what to mount and how. I tried "mount /dev/md0 /sysroot" but the answer was "Mounting /dev/md0 on /sysroot failed: Invalid argument"
But now, I don't know neither how to check the fullness of the volume nor where to find the logs. Is it a bad idea to remove the logs if I find them (don't know where to move it and by the way it would not empty the volume by only moving it)?
The first command will tell you the amount of free space in the volume (among other things). The second will tell you the number of free inodes - which can sometimes run out (especially if you use ReadyDLNA.)
Normally the OS partition will be at most 25% full.
You can truncate logs by entering
echo > log-filename
Any files in /var/cache can be safely deleted (though you might want to preserve the top-level subfolders).
The problem is that when I enter into sysroot and type the df commands, there is the message "-sh: df: not found". And I cannot find any "folder" called OS or so...
Edit : I removed all files *.log.old in sysroot/var/log because I assumed it were useless ones.
I tried to remove the disk 4 and skipping volume check but it blocked while resyncing the volume. Turned off, putting back disk 4 and booting but stuck at the same phase (booting) and with the disk 4 blinking...
Your inodes are fine. My own NV+ uses 23% of the OS partition, so your usage is on the high side. I'd expect your system to boot though - you still have more than half the space left.
What add-ons do you have installed? Have you installed things with ssh? Do you use ReadyDLNA?
I did not understand well the "truncate" phase. Does it empty the various logs by replacing them with "new" ones?
That echo command preserves the file itself, but the contents are completely empty. You'd do it file-by-file, and only on log files that seem excessively long.
I tried to remove the disk 4 and skipping volume check but it blocked while resyncing the volume. Turned off, putting back disk 4 and booting but stuck at the same phase (booting) and with the disk 4 blinking...
First, it can't resync the volume if one disk is missing.
I am wondering if you should try tech support mode again, and this time attempt to mount the C data volume. If that works, you can at least get the data off.
Ok so no problem with the logs? So no need to truncate them? Anyway I can't see the size of the files...
I don't have any add-on but the time machine one. I don't know what is ReadyDLNA...
Concerning the reboot, the command "reboot" did not respond so I tried "shutdown -a -t 0 time now" without success. I had to close my bash and then "reboot" worked... Strange... Next time I will try the way you indicated me.
So, I should mount C instead of hdc1? But how can I save my data/transfer them?
I did "start_raid.sh" (as previously) and then tried "mount -t proc proc /proc" but it said "mount: Mounting proc on /proc failed: Device or resource busy".
There is "mount /dev/md2 /dev/c/c" . I have X-Raid so should I mount "md2" or should I mount another volume?
I see that I have to unmount all before rebooting : how can I unmount all? With unmount * ? "unmount sysroot"?
Still not working despite many attempts. I succeed in launching samba but all the data are not reachable because of the impossibility to mount the data volume (is asks me to specify the filesystem whil mounting on /dev/c/c).
Have you run any checks to check disk health? That would be the first step.
To check disk usage with the sysroot mounted you can run
# /sysroot/bin/df -h
# /sysroot/bin/df -i
There's no need to chroot in simply to run df.
If you're going to chroot in you'd be best to do e.g.
# mount --bind /dev /sysroot/dev
# mount --bind /dev/pts /sysroot/dev/pts
# mount --bind /proc /sysroot/proc
# chroot /sysroot /bin/bash
The first thing to do would be to check the disk health. If there's a bad disk that could be causing your issues and that problem should be considered before moving to try to mount the data volume.
There's the get_ata_errors command that can be run outside the chroot. Inside there's the smartctl command.
We use LVM on RAIDiator, so after starting the RAID you'd need to scan for the volume group, change the status of the group to active and then mount the volume. /dev/c/c isn't the mount point, but rather what you need to mount.
The mention of /dev/md2 is for Flex-RAID which you clearly aren't using. Even then I think you'd need to use the commands for LVM to mount the data volume.
Thank you but I really don't know how to use LVM and so to do the scan.
For the disks, I would be very surprised if one is faulty because I did a firmware update one day before the "crash" of the NAS and I looked to the reports about the disks that seemed to be in good health. I admit that I took the habit to check it regularly because I experienced a double disk crash one day and it was really hard to back up data...
