Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!

mprindle · ‎2014-08-23

iamthemitch wrote:
Hi,

Well, I can believe that I'm the only one with this issue, but I didn't find a solution (neither in the forum, nor Google...)

I have a Ultra 2 running OS6 6.1.4 successfully.

But I can't activate alarms, because of the below alarm being triggered every 5 minutes
V5_0 voltage in enclosure 'internal' is out of spec. (4,74V).
<snip>

Did you ever find a solution to this? I just upgraded mine and I'm now getting the exact same warning with the same listed voltages

Edit: Found the solution on page 69

http://www.readynas.com/forum/viewtopic.php?f=51&t=70133&p=422383&hilit=voltage#p422383

SurplusGadgets · ‎2014-08-30

This likely is more a BTRFS (filesystem) issue than one of upgrading to OS 6 on legacy hardware but ....

Be prepared to drop down to SSH management with OS 6 and BTRFS, as I have now learned. Specifically, my lightly used, mostly read-only volume had (unbeknowsnt to me) 27 CRC errors on file blocks allocated within files. Once this occurs, you cannot copy the file nor delete it. Not clear if the ReadyNAS Frontview interface has enough functionality to resolve this issue that OS6 and BTRFS introduce.

Problem:
File would not copy (be read) without the host OS receiving a report of a low-level I/O Block error. This is in the host machine mounting the ReadyNAS volume over SMB. Windows File Explorer and Robocopy simply reports it as a "file copy error". BeyondCompare reports it as "Unable to copy; a device attached to the system is not functioning". There is no alert reported by the ReadyNAS or in the log. It is not treated by the disk as a sector fail to be reallocated as the disk CRC was fine. BTRFS, at a higher level, has added CRC checking to blocks. But a failure at this filesystem level gets reported up simply as an I/O error when trying to read the file block; which is not expected by the OS and normally indicates a basic disc failure that should generate an alert from the READYNAS.

Diagnosis:
The CRC for a block within a file gets corrupted (actually 27 blocks in 23 files for me) . Likely at creation time. The file contents (after fixing) appears to be fine. This can only be detected with a BTRFS Scrub or by looking at the internal Linux message log (dmesg). Key is the error is not detected and reported during operation by the ReadyNAS. You have to go look for the problem and diagnose it yourself. Maybe something Netgear will fix in the future?

Note: not clear if the Frontview Volume option to "Scrub" is the same function as given below. Not sure how Frontview would report errors if Scrub is run from there either. For me, the "checksum" checkbox on the Volume properties pop-up was cleared. Not sure if this is supposed to turn off BTRFS block checksum function and checking. It did not for me. Not sure if it was always cleared or unchecked by default.

Solution:
DISCLAIMER: Dropping down to SSH access with your ReadyNAS generally voids your warranty. And unmounting an MD RAID volume to fix Filesystem errors is definitely core, kernel level activity. Do so with extreme caution and only if very comfortable with Linux/Unix low-level functions.

Determine the MD RAID device identifier of the VOLUME with errors. I simply used "df" to figure out the VOLUME_NAME and device of "md127":

root@READYNAS:~# df
Filesystem       1K-blocks        Used Available Use% Mounted on
rootfs             4190208      336380   3427300   9% /
tmpfs                10240           4     10236   1% /dev
/dev/md0           4190208      336380   3427300   9% /
tmpfs              2020340           0   2020340   0% /dev/shm
tmpfs              2020340        6000   2014340   1% /run
tmpfs              2020340           0   2020340   0% /sys/fs/cgroup
tmpfs              2020340           0   2020340   0% /media
/dev/md127     11706500352 11119192052 585113420  96% /VOLUME_NAME
/dev/md127     11706500352 11119192052 585113420  96% /home
/dev/md127     11706500352 11119192052 585113420  96% /apps
/dev/md127     11706500352 11119192052 585113420  96% /run/nfs4/data/SHARE_NAME

Run a scrub on the mounted VOLUME_NAME to verify the errors; wait for it to finish before proceeding further


root@READYNAS:~# btrfs scrub start /VOLUME_NAME
scrub started on /VOLUME_NAME, fsid c4da3ed4-d080-4e0e-83d9-b223001eef05 (pid=4353)
###
### Repeat the [b]Status[/b] command below as needed until a final report as shown is given.  
###   Frontview detects the Scrub and will report its progress but simply no longer indicates the operation once done.
###
root@READYNAS:~# btrfs scrub status /VOLUME_NAME
scrub status for c4da3ed4-d080-4e0e-83d9-b223001eef05
        scrub started at Fri Aug 29 22:08:27 2014 and finished after 33028 seconds
        total bytes scrubbed: 10.34TiB with 27 errors
        error details: csum=27
        corrected errors: 0, uncorrectable errors: 27, unverified errors: 0
#
# If desired, confirm details of errors by looking at message log from Linux kernal and utilities:
#
root@READYNAS:~# dmesg 
...
btrfs csum failed ino 297 off 9038946304 csum 2266718443 private 71772232
### Sample message entry above for when trying to read a block with a bad checksum; one or more entries for each attempt to read the bad block
....
btrfs: checksum error at logical 197623537664 on dev /dev/md127, sector 388097008, root 266, inode 297, offset 9038946304, length 4096, links 1 (path: <<directory path and file name within share>>)
btrfs: bdev /dev/md127 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0
btrfs: unable to fixup (regular) error at logical 197623537664 on dev /dev/md127
### Sample message for each block with a checksum error found in the scrub; identifies the paths and files that will not read/copy
....

Prepare to fix the problem by unmounting the MD RAID volume (cannot fix file system while mounted; cannot do this in Frontview to my knowledge):


###
### Just to verify the MD knows about the volume
###
root@READYNAS:~# mdadm --detail /dev/md127
/dev/md127:
        Version : 1.2
  Creation Time : Sun Jul 27 12:58:41 2014
     Raid Level : raid5
     Array Size : 11706500352 (11164.19 GiB 11987.46 GB)
  Used Dev Size : 3902166784 (3721.40 GiB 3995.82 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Fri Aug 29 23:21:49 2014
          State : active
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           Name : 5e24f95e:data-0  (local to host 5e24f95e)
           UUID : 9c032697:d91707d1:65d32704:66dc17d2
         Events : 16927

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       8       19        1      active sync   /dev/sdb3
       2       8       35        2      active sync   /dev/sdc3
       3       8       51        3      active sync   /dev/sdd3
###
### OK, lets unmount
###
root@READYNAS:~# umount /dev/md127
###
### repeated umount command 4 times as there were four mount points for this filesystem shown in "df"; not just the main volume
### have to make sure nothing is attached to or using the volumes otherwise umount will fail (e.g. your login may be using /home)
###

Fix the filesystem by running BTRFS Check (formerly known as btfsck):


root@READYNAS:~# btrfs check --fix-crc /dev/md127
Fixing bad CRC
Checking filesystem on /dev/md127
UUID: c4da3ed4-d080-4e0e-83d9-b223001eef05
checking extents
ref mismatch on [2700638683136 32768] extent item 33, found 1
Errors found in extent allocation tree or chunk allocation
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
checking csums
checking root refs
found 5942559407194 bytes used err is 0
total csum bytes: 11083458464
total tree bytes: 11775672320
total fs tree bytes: 27557888
total extent tree bytes: 55345152
btree space waste bytes: 358773385
file data blocks allocated: 11349461471232
 referenced 11349461430272
Btrfs v0.20-rc1
###
### NOTE: Fix-CRC was not enough for me.  Had to recreate the Checksum tree.
###
root@READYNAS:~# btrfs check --init-csum-tree /dev/md127
Creating a new CRC tree
Checking filesystem on /dev/md127
UUID: c4da3ed4-d080-4e0e-83d9-b223001eef05
checking extents
Reinit crc root
found 0 bytes used err is 0
total csum bytes: 0
total tree bytes: 0
total fs tree bytes: 0
total extent tree bytes: 0
btree space waste bytes: 0
file data blocks allocated: 0
 referenced 0
Btrfs v0.20-rc1
###
###  At this point, need to remount the various file systems you unmounted before.  I found it simplest to reboot.  
###     Either use Frontview to restart the ReadyNAS or the shell if you feel comfortable ...
###
root@READYNAS:~# shutdown -r

Verify the problems are fixed (although you should be able to copy the file now as a verification as well):


###
### Maybe just do the Volume Scrub using Frontview after a reboot?  Not sure if the same but likely.
###
root@READYNAS:~# btrfs scrub start /VOLUME_NAME
....
###
### Wait for scrub to finish and report all ok
###
root@READYNAS:~# btrfs scrub status /VOLUME_NAME
....

StephenB · ‎2014-08-30

I believe the frontview scrub should have repaired the damage unless unless the parity blocks were also damaged.

SurplusGadgets · ‎2014-08-30

StephenB wrote:
I believe the frontview scrub should have repaired the damage unless unless the parity blocks were also damaged.

No damage to data (RAID or otherwise) if that is what you were implying by "parity blocks". Only BTRFS Checksum's were corrupted. Checksum and CRC fixes appear to require the filesystem be offline. And Frontview's Scrub does not take the volume offline while working. So suspect they are doing the simple BTRFS SCRUB command, which works on a mounted filesystem, but then cannot correct many errors it detects. See my results of commands in the last post.

StephenB · ‎2014-08-30

Yes I did look at them. So your checksums were wrong, and but the data itself was fine. btrfs scrub could not fix the checksum errors. btrfs check fixed the errors with the volume off line.

You are correct in thinking that the NAS does a simple btrfs scrub when you do the frontview scrub. At least top shows the command as "btrfs scrub start /volume"

Why do you think the checksums were wrong in the first place?

SurplusGadgets · ‎2014-08-30

StephenB wrote:
Why do you think the checksums were wrong in the first place?

That is the $10,000 question. Would need a bit of investigating -- hardware as well as software. Many places for it to go wrong. But wanted to at least make people aware that a workaround exists for the corruption that can be introduced. The CRC stored or calculated incorrectly does appear to be a rarer occurrence -- only 27 out of 2.7 billion blocks written had the error -- hmm, that already looks like too much coincidence. Maybe why Netgear chose not to release OS6 with BTRFS on their older hardware?

StephenB · ‎2014-08-31

There are two pieces of good news though. First is that the scrub detected it (though it did not fix). The second one (in your case anyway) there was no data loss involved. People here can verify their own systems with your first step.

tijgert · ‎2014-09-01

Hi fellas,
I read a lot about Pro's and Plus's upgrading to OS6, but not too many people with Ultra's and only one person with an Ultra 6.
I'm wanting to upgrade my Ultra 6 to OS6 but would really like to hear first from people in the know if there any known compatibility issues or known problems (other than non working Genie and Antivirus that might F the system up). I have absolute zero knowledge of Linux so if I'd need to go into SSH then I'm Fubar.

Also;
- Does performance suffer under OS6 since the Ultra's only have a puny Atom CPU.
- And in that light, do temps go up noticably? (Although my CPU is hard stuck at 50c...)
- On my RN516 there is currently no idle drive spin down which simply aggravates me. My RNDU6000 under OS4 DOES have idle drive spin down. Is it safe to assume then that when I upgrade my Ultra 6 to OS6 that I will lose idle drive spin down? (Until 6.2 comes out supposedly).
- The post above somewhat concerns me. If frontview scrubbing is so useless in OS6 then how can I, as nitwit end user, fix any file errors? (The whole SSH spiel is over my head, even if it is interesting).
- Does OS4 have this scrubbing effectiveness limitation? (I might wanna stick with that if it doesn't).
- Is there some form of tool or simpler command to enable effective scrubbing under OS6?
- Can anyone simply confirm the voltage reporting issue and fan issue are no longer issues with 6.1.9 on an Ultra 6?

I'm not afraid to experiment but would like to know a little better what I'm walking into if others already suffered it. Rebuilding a 30TB array under OS4 again and copying the files again will take over a week if it should be a failure.

Skywalker · ‎2014-09-03

For the record, "fixing" CRCs is generally very bad advice. I have seen no verified cases of bad CRCs on an x86 machine (although that of course does not mean they don't exist), but I have seen verified cases of bad data with good CRCs. So, if you see an I/O error due to a checksum mismatch, odds are that the data is corrupt. So rewriting the CRCs based on the current data basically "bakes in" data corruption. Starting in 6.1.9, you can remount the volume with the "recovery" option to allow bad data to be read, rather than just returning an I/O error.

tijgert · ‎2014-09-04

All right.. so even IF there should be an error that can only be fixed by un/dis-mounting the filesystem, now the firmware can do it too for basically Linux inept people... (like myself, but only because of ignorance, not stupidity).
Just when my OS4 is at 91.5% resyncing... Now I can do it all over again for OS6 😉

One teeny tiny thing that's holding me back though... what in case I shoud want to revert back to OS4?
I know of the link with the 4.2.26 image, but it says "you will likely need to do a USB Boot Recovery followed by a factory default to get a working system again."
What is a USB Boot recovery?

And will this OS4 reverting package revert *any* OS6 package that's installed? Or just the 6.1.7 that's mentioned in the beginning of this thread?

mdgm-ntgr · ‎2014-09-04

There is a downgrade image here (may be updated from time to time): http://www.readynas.com/forum/viewtopic.php?f=35&t=75198

If you have trouble downgrading with that image let me know.

tijgert · ‎2014-09-04

Ah you beat me to it 🙂 I just edited my post...
But it just somewhat accentuates my point, why does that image need to be updated?
I mean, in case we are several OS6 verisons further ahead later on and the OS4 revert image is NOT being updated anymore... would that be an issue?

mdgm-ntgr · ‎2014-09-04

tijgert wrote:

I know of the link with the 4.2.26 image, but it says "you will likely need to do a USB Boot Recovery followed by a factory default to get a working system again."

That is just a warning for users with a new model e.g. 516. If you try to put e.g. 4.2.26 on a 516 it won't work. You can only downgrade legacy systems to 4.2.26.

tijgert wrote:

And did will this OS4 revert package revert *any* OS6 package that's installed? Or just the 6.1.7 that's mentioned in the beginning of this thread?

It can be used to downgrade any legacy ReadyNAS that has been upgraded from OS4 to any OS6 firmware back to OS4.

Do note that like upgrading to OS6 requires a factory default, so does downgrading.

tijgert · ‎2014-09-09

So I took the plunge and OS6'd my Ultra 6...

It started nice when the system came up telling me the fan was dead. Apparantly you have to switch the fan from the left header to the right header, then it showed. The fan started at 1500rpm and quickly went down to around 1200rpm after a short while. It seems to slow down further at a snale's pace and is at sub 900rpm 45 mins later.

OS6 doesn't show 2 fans and their respective rpm's when 2 fans are hooked up, OS4 did. It's a bit of a shame really but I don't recall seeing a second fan header in my RN516 so the code might just be missing for that. The other header does scale the fan down after a while as well and might just be duplicating the other fan's profile, but I didn't confirm that.

So far no (5v) voltage fault indication but I'll let it run overnight and see how it goes in the a.m.

I do have an annoying problem though:
On OS4 (4.2.26) the CPU temp was always fixed at exactly 50c/122F. Either after a hard days work or when just switched on in a freezing room, it didn't matter it was always showing 50c/122F.
I recently updated the bios to the latest version to enable/fix scheduling and before and after it behaved the same so that shouldn't be the cause unless some old bios setting disabling the CPU temp monitoring was once set and remained.
On OS6 (6.1.9) the CPU is fixed at -1c/30F which is obviously wrong. I believe It is now quite safe to say that the CPU temperature indication is not working and it's not the OS's fault since it does this on two completely different OS's.
I haven't read about anyone having this problem on their Ultra 6's running OS4 ever, or OS6 for that matter, does anyone have any thoughts on it?
Where is that sensor located anyway? Any hacks or fixes applicable?

Question:
I have OS6 on my RN516 (obviously) and am running it with the exact same type and number of drives as my Ultra 6 that's also running OS6.
The Ultra6 is an exact copy of the RN516 including users, shares and files. It's a backup.
Is it possible to upload the RN516's configuration files to the Ultra 6 as to immediately have all settings set correctly? (I'd have to change the Ultra 6's name and IP obviously).

Remark:
One thing I really don't like so far is that on OS6 you can set the wake up/shutdown schedule only per HOUR while on OS4 it was per 5 minutes. I can't see the gain or logic in that.

mdgm-ntgr · ‎2014-09-09

Does adding the RNDU6000 file make any difference?: http://www.readynas.com/forum/viewtopic.php?p=411650#p411650

tijgert · ‎2014-09-09

I just found that topic 20 mins ago. I did not add that file and am sorry to say that I don't know how to. Care to take me ever so slightly by the hand? Just this once.
I'm a fast learner.

Bigbearf · ‎2014-09-18

@ Skywalker and mdgm.
Anyone running OS 6.1.9 on a Pro6? If so, anything any fan issues? I would like to upgrade and use the Pro 6 as a backup to a 516 via replicate.

mdgm-ntgr · ‎2014-09-18

BigBearf wrote:
@ Skywalker and mdgm.
Anyone running OS 6.1.9 on a Pro6? If so, anything any fan issues? I would like to upgrade and use the Pro 6 as a backup to a 516 via replicate.

Do you have a stock CPU or a 3rd party one?

You can give it a try and if it doesn't work for you downgrade back (note: this requires another factory reset).

Xophile · ‎2014-09-23

Hi!

I have a Readynas ultra 4 with os6 installed.

When I try to add an external hard through USB, it doesn't show. The drive is formatted with NTFS.

Any ideas where to begin? Is this a known issue on legacy hardware and os6 maybe?

Thanks!

CharlesR · ‎2014-09-23

Since my question/thread was deleted elsewhere (in the Beta forum) does anyone know if you can downgrade from 6.2 to 4 on the old school hardware? In my case the Ultra Plus.

mdgm-ntgr · ‎2014-09-23

Not deleted. Locked and moved: http://www.readynas.com/forum/viewtopic.php?f=162&t=77773

Should be possible. Would need to check if the downgrade image needs to be made with a different header again or if the current one used is fine. Downgrading does require a factory reset.

mdgm-ntgr · ‎2014-09-28

Locking this thread. Please open new threads for new issues.

cpu8088 · ‎2015-10-08

@AMRivlin wrote:
Directions to upgrade your x86 legacy hardware from 4.X to 6.x
Supported so far: pro 2/4/6, ultra 2/4/6, old pro / Pioneer Pro, 2100v2
Not Supported: NVX and 2100v1

You will lose all of existing data on board.
You will most likely lose support from NTGR

1. BACKUP, BACKUP, BACKUP
2. Download 6.0.X package from NTGR
3. Edit the latest IMG for instalation by 4.2 Frontview
3. Install via 4.2.x menu
4. Reboot
5. Factory Default the system
Specifics here: http://netgear.nas-central.org/wiki/Con ... ReadyNASOS

OR (once your data is backed up)

Optional (do before step 2 below): R4toR6_Prep_Addon.bin (26 KB) (upload before modified IMG, don't reboot, avoids the need for manual factory default in between)

OS6 in 3 Steps: 1. Download pre modified IMG, (see link above to see what has been modified)
2. Upgrade firmware in Frontview 4.2 (with above file)
3. Reboot & factory default via boot menu

Been following the above steps with no avail.

I have an ultra 4 with os 4.2.27 wanting to upgrade to 0s6.4.0

installed thru 4.2.27 with R4 to R6 bin file and then the local update with 6.4.0 x86 64.img takes over 1 hour and still upgrading!!!

what is wrong?

can anyone help?

grimloch · ‎2015-10-11

I updated both of my ReadyNAS Pros to 6.4. One seems to be running fine, but the other survived a couple reboots but some services like ReadyCLOUD didn't seem to be connecting. I did a full shut down, powered it back on and now it's just stuck saying "READYNAS" on the OLED display. The drives do not spin up, NIC doesn't seem to connect to router, OS doesn't load, just "READYNAS" on the display. I cannot access the boot menu with the drives in or with them out. I am at a loss.. Any suggestions?

petermac · ‎2015-10-13

Just upgraded my Pro 6 to 6.4 from 6.2.4 and now the fans shutdown after the system gets up and running. Temps on the inside of the case are in the 70C range which is bad (normal is 30C). My other ReadyNAS 316 is running just fine with 6.4. Unfortunately you CANNOT go backwards from 6.4 to previous releases of ver 6.

Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!