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

tadgy1 · ‎2013-12-08

darshan wrote:

I am knowledgeable enough to know that the data is still there, as no low level formatting has happened. But I am not sure if there is an easier way than a proper data recovery process to get this information back.

I'm afraid that assumption is a little wrong.

As far as I could tell, from the first boot of 6.x a new btrfs filesystem is created on your drives. Since btrfs is a totally different filesystem from ext* (which 4.x used), it would have had to re-format the disk table/inode structure to suit the new filesystem. That is a data destructive operation - unless (and i'm no expert on this subject) btrfs does "lazy" init of it's filesystem elements (ie, it initialises them as it begins to use the space).

However, even with the lazy init (if btrfs does indeed do that, which remains to be seen...) the filesystem superblock(s) will have been over-written making them un-mountable as the old ext* filesystem. Also given the OS6 init process puts a load of stuff on the disks, depending on where your data was located on those disks (in a physical sense), it may have also been over-written already.

In short, you are unlikely to recover any data by going back to 4.x; and even if you are, it's going to need forensic data-recovery tools, a truck load of desire and a metric shit-tonne of time to do so.

Sorry to say it, but unless you've got £4m in bitcoins on that disk, you're better off having a few shots of your favourite tipple and cutting your losses.

mangrove · ‎2013-12-08

tadgy wrote:
As far as I could tell, from the first boot of 6.x a new btrfs filesystem is created on your drives. Since btrfs is a totally different filesystem from ext* (which 4.x used), it would have had to re-format the disk table/inode structure to suit the new filesystem. That is a data destructive operation

This is partly correct, in that it is NOT a completely data-destructive operation, but its a metadata-destructive one. It is also complicated by the fact that there is a new, blank filesystem on top of the old one, but the simple XORing of a resync isn't a data-destructive operation in itself (it doesn't write zeros, it XORs the existing data, MD doesn't know or care about which file system is on the resulting datablob). Data is still there, but it might be hard getting it out.

tadgy wrote:
even if you are, it's going to need forensic data-recovery tools, a truck load of desire and a metric shit-tonne of time to do so.

This is 100% right. It would take several days, probably a week of work, if at all possible.

tadgy1 · ‎2013-12-08

mangrove wrote:
This is partly correct, in that it is NOT a completely data-destructive operation, but its a metadata-destructive one. It is also complicated by the fact that there is a new, blank filesystem on top of the old one, but the simple XORing of a resync isn't a data-destructive operation in itself (it doesn't write zeros, it XORs the existing data, MD doesn't know or care about which file system is on the resulting datablob). Data is still there, but it might be hard getting it out.

We might be talking cross-purposes here.

You're talking about the MD driver and how it distributes across an array; which is - as you say - filesystem agnostic.

But, in the process of upgrading to 6.x he's gone from ext4 as the filesystem on that MD device to another filesystem that has an utterly different on-disk data structure.

Imagine the on disk data "blocks" like this:
For ext4: XXYYYY
For btrfs: XYXYXY
Where X is a bit of metadata, and Y is actual data.
(This is only an example, the structure is utterly more complex and not like this in any way - it serves only as example)

The process of initialising the btrfs filesystem *may* have created those metadata blocks all over the disk, where actual data may have been in the ext4 filesystem. This depends on the init process for btrfs, which I have no idea about.

So, even if you could trick the system into recognising the filesystem as ext4 (unlikely at best), the on-disk data is going to be completely in the wrong format for it to try and recover anything.

darshan · ‎2013-12-08

thanks for the replies. I appreciate the insight (not being facetious, honest).

I am no expert, but I'd say that the initialization was rather on the slow side of things (I have 4x2TB disks and took less than 5 minutes to change the whole thing), so I am prone to think it was a lazy start. I am in the process of securing USB enclosures, r-studio, a spare machine to create images and scour the surface of the disks.

At the end of the day I only want to recover around 15GB to 20GB of data, which, yes, I need to first locate.

Lesson learnt the hardest way possible.

coolsteef · ‎2013-12-10

Hi guys,

first of all great respect for the ability to put OS6 on my ReadyNAS Ultra 2. I started with 4.2.24 and upgraded to 25 after which I went uploading files to my NAS to test the speed. I was happy with the 60MB/s transfer it managed but couldn't resist to try the new features of OS6. After installing which went like a charm I tried uploading files again and got a staggering 80MB/s. I'd say that's worth the upgrade...
However I seem to have the same issues others experienced. I get sudden drop outs after which my NAS isn't reachable by SSH and the file tranfer hangs for a few minutes after which my iMac gives me an error. Sometimes it continues in time again to complete the transfer but more often I need to hard reset the NAS. I've had a better experience with a transfer via FTP (2 threads) to upload the data to my 2x2TB drives in JBOD but now it hangs more often even when trying to copy a 2GB video file.

My question is, is this also related to the BTRFS which will be fixed in the 6.1.5? Or am I better of with the 4.2.24 Radiator although it will be less fast. I don't mind the factory reset since my data is still on the NAS and external harddrives (which I intend to wipe after everything works as it should).

radikaled · ‎2013-12-23

Hello everyone,

I've been a long time ReadyNAS user but this is my first time posting to the forum. Like many of you I was quite disappointed in Netgear's decision to not officially support OS6 on "last" generation hardware. I'm even more dissapointed in their decision to use BTRFS... but I digress.

In any case I installed 6.1.4 on my ReadyNAS Ultra 2 (Thanks guys!) and for the most part appears to work great. At first glance I can't be too sure if the fan/temp sensors are working as they should. My system runs at 70-80c (CPU) and 30-40c (SYSTEM) which should be within spec from what I understand.

Anyway...

The reason I'm posting this is because I recently upgraded my ReadyNAS to 6.1.5 (RC?)

Original post is here([url] is OFF for me apparently):

http://www.readynas.com/forum/viewtopic.php?f=154&t=74192&start=30#p413593

I simply downloaded the relevant image file and upgraded through the GUI, did a factory reset (apparently required as discussed, and through the GUI), and am now running 6.1.5 😄

I've only been playing with it for a couple of hours but all seems well!

Some nice shell output to show you the differences...


root@readynas:~# btrfs filesystem show
Label: '758ad486:data'  uuid: 642a625a-071b-4939-b699-61c31ab5e14e
        Total devices 1 FS bytes used 4.38GB
        devid    1 size 926.89GB used 7.04GB path /dev/md127

Label: '758ad486:root'  uuid: d69cc7ba-3242-4f03-97e9-5ba005fbf10a
        Total devices 1 FS bytes used 275.36MB
        devid    1 size 4.00GB used 854.31MB path /dev/md0

Btrfs v0.20-rc1
root@readynas:~# cat /proc/mdstat
Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md127 : active raid1 sda3[0] sdb3[1]
      971910784 blocks super 1.2 [2/2] [UU]
      [===>.................]  resync = 17.5% (170255616/971910784) finish=118.5min speed=112731K/sec
      bitmap: 7/8 pages [28KB], 65536KB chunk

md1 : active raid1 sdb2[1] sda2[0]
      523712 blocks super 1.2 [2/2] [UU]
        resync=DELAYED

md0 : active raid1 sdb1[1] sda1[0]
      4190208 blocks super 1.2 [2/2] [UU]

unused devices: <none>
root@readynas:~# btrfs-show-super /dev/md127
superblock: bytenr=65536, device=/dev/md127
---------------------------------------------------------
csum                    0x546e2911 [match]
bytenr                  65536
flags                   0x1
magic                   _BHRfS_M [match]
fsid                    642a625a-071b-4939-b699-61c31ab5e14e
label                   758ad486:data
generation              44
root                    58949632
sys_array_size          226
chunk_root_generation   33
root_level              0
chunk_root              21004288
chunk_root_level        0
log_root                0
log_root_transid        0
log_root_level          0
total_bytes             995236642816
bytes_used              4700119040
sectorsize              4096
nodesize                32768
leafsize                32768
stripesize              4096
root_dir                6
num_devices             1
compat_flags            0x0
compat_ro_flags         0x0
incompat_flags          0x21
csum_type               0
csum_size               4
cache_generation        44
dev_item.uuid           e8c6792a-7957-4555-b988-14218d6b1a0b
dev_item.fsid           642a625a-071b-4939-b699-61c31ab5e14e [match]
dev_item.type           0
dev_item.total_bytes    995236642816
dev_item.bytes_used     7553941504
dev_item.io_align       4096
dev_item.io_width       4096
dev_item.sector_size    4096
dev_item.devid          1
dev_item.dev_group      0
dev_item.seek_speed     0
dev_item.bandwidth      0
dev_item.generation     0

root@readynas:~# uname -a
Linux readynas 3.0.101.RNx86_64.2.1 #1 SMP Thu Dec 5 12:31:10 PST 2013 x86_64 GNU/Linux
root@readynas:~#

Happy Holidays!

Cheers,

mdgm-ntgr · ‎2013-12-23

The factory reset after updating to 6.1.5 from an earlier ReadyNAS OS 6 is recommended but not mandatory. Once 6.1.5 has been released the update image will be replaced with one to update direct to 6.1.5. So in the future users newly upgrading their systems from 4.2.x to ReadyNAS OS 6 will get the benefits of 6.1.5 when the required factory default takes place.

radikaled · ‎2013-12-23

mdgm wrote:
The factory reset after updating to 6.1.5 from an earlier ReadyNAS OS 6 is recommended but not mandatory. Once 6.1.5 has been released the update image will be replaced with one to update direct to 6.1.5. So in the future users newly upgrading their systems from 4.2.x to ReadyNAS OS 6 will get the benefits of 6.1.5 when the required factory default takes place.

Based on the following thread it sounds more like it will be mandatory:

https://www.readynas.com/forum/viewtopic.php?f=65&t=73537&start=45#p411589

Although strictly speaking I guess you could get away with not using the larger metadata block sizes. Your second statement makes sense since upgrading directly to 6.1.5 from 4.2.x requires a factory default anyway.

Cheers,

sanman1 · ‎2013-12-24

Is there a way to modify the 6.1.5 RC so that it can run on a ReadyNAS Pro 2? I tried to upgrade from 6.1.4 but it returns "... not for this device".

Thanks!

My fault. Tried to use the ARM image for my 102 on the Pro 2, which is Intel. 😕

chirpa · ‎2013-12-24

Did you use the x86_64 image on the Pro 2 already running OS6?

demetris · ‎2013-12-26

ReadyNASOS V6.1.5 Final out

ReadyNAS OS V6.1.5 Release Notes:

Enhancements & Bug Fixes:

Improved Active Directory handling of slow/remote connections by adding an option to force authentication each time. The "Not sync ADS accounts to local DB" option should be used when each authentication is validated with the ADS server.
Fixed system instability issue with Photos II image import.
Fixed ReadyNAS 4220 power supply unit alarm.
Compatibility improvements for Windows 8.1 Internet Explorer 11.
Fixed smart snapshot automated data pruning issue which could cause devices to not shutdown properly.
Fixed anti-virus engine to address out of memory error and issue preventing successful Windows backup.
FTP permissions update. When new files or sub-folders are created over FTP, file or sub-folder permissions are set to the same settings as the share-folder permission.
Fixed drag and drop file compatibility with Chrome.
SMB security patches applied.
Kernel patches applied.
Improved performance with large volumes (Most likely seen on the ReadyNAS 104). A factory default is required to make the changes. Copy all data off the ReadyNAS, upgrade the firmware, factory default the unit, and copy all data back onto the device

Deployment Notes / Limitations:

After deleting a volume and creating a new one the old volume may still show up until after a reboot.
WOL will not be supported on 3220/4220 at this time for 10GbE. Use 1GbE port for WOL.
Disk failure on the 3220 and 4220 will not show LED failure for the exact drive that has failed, use local web admin page for disk failure information.
Deleting volume with ReadyNAS Vault enabled will show error. User must turn off vault first.
Can't set up bond on interfaces that are not already connected.
If the USB key is missing from the system for Encryption, there is no error message presented.
If USB key is missing for encryption, the user has to wait on a 10 minute timeout. After that, the encrypted volume is displayed as inactive.
If a Flex-RAID volume has been expanded, the volume cannot be switched back to X-RAID mode.
If you wish to remove a USB storage device, you should follow the safe removal procedure of first unmounting before removing the USB device. If these steps are not followed then you may develop errors on the file system on the USB device.
UPS may report incorrect status after reboot, it may send out a warning during this time. After sometime, the UPS will start reporting the correct information.
ReadyNAS 102, 104, and 2120 only support creating iSCSI LUNs 8TB and smaller.

chirpa · ‎2013-12-26

You left out the Limitations section, BROKEN USB SUPPORT.

amacbr1 · ‎2014-01-02

sanman wrote:
Is there a way to modify the 6.1.5 RC so that it can run on a ReadyNAS Pro 2? I tried to upgrade from 6.1.4 but it returns "... not for this device".

Thanks!

My fault. Tried to use the ARM image for my 102 on the Pro 2, which is Intel. 😕

Hello sanman, I also have a Pro 2 with Raidiator 4.xxx running, and I would like to update my Pro 2 to OS6. Where can I get the link to the last revision of the firmware? Can somobody explain upgrading steps to follow?

thanks

mdgm-ntgr · ‎2014-01-02

Just modify the link to update from 4.2.x to 6.1.4 to say 6.1.5 and you can update direct to that. Due to the issues with 6.1.5 I've held off on replacing the direct update links for now.

chirpa · ‎2014-01-04

USB issues addressed in 6.1.6 RC3 beta... viewtopic.php?f=154&t=72282

mdgm-ntgr · ‎2014-01-04

Once 6.1.6 goes final I will replace the links with one to update direct to 6.1.6.

rxcfirst1 · ‎2014-01-08

mdgm wrote:
1. You can downgrade if you don't like it (I can PM you a link to an image to downgrade if you like. I might even post a link at some point). You should maintain a regular backup anyway

2. If you backup important data regularly it should be low risk. If you run into issues the community here will do its best to help.

Hi mdgm, could you kindly PM me a link for 4.x downgrade image. I tried modify the header to "version=6.2.0" but the readynas complains about not being ReadyNas OS image.

Reason for downgrade is because of the USB voltage issue with 6.1.5, I tried 6.1.6 RC3, still the same problem. So I'm trying to downgrade to 4.x then retry R4toR6_6.1.4

Thanks

mdgm-ntgr · ‎2014-01-08

Could you try 6.1.6-RC5

amacbr1 · ‎2014-01-10

I succesfully installed 6.1.4 on my Pro 2. It works fine, but it propose me an update to 6.1.5. Can I update directly? In case I want to update to 6.1.6 could I update with original .bin or do I need to modify header again?

Thanks for support

mdgm-ntgr · ‎2014-01-10

Only need modified bin once. After updating to OS6 need to use ordinary firmware image for further updates.

Jurgen76 · ‎2014-01-11

Hi,

I have got a Ready Nas (RNDU6000 ) with the following version of RAIDair 4.2.25. I follow everything but everytime I upload the files "R4toR6_6.1.4.bin" between 20 and 23% I have got an error: "local file upload failed" I download again and again the files but without success.

Have you got an idea?

Regards

mdgm-ntgr · ‎2014-01-11

OS partition might be full.

Jurgen76 · ‎2014-01-11

I only use 18% of 4606 Gb...

mdgm-ntgr · ‎2014-01-11

I was talking about your 4 GB OS partition not your data volume.

rxcfirst1 · ‎2014-01-11

rxcfirst wrote:
mdgm wrote:
1. You can downgrade if you don't like it (I can PM you a link to an image to downgrade if you like. I might even post a link at some point). You should maintain a regular backup anyway

2. If you backup important data regularly it should be low risk. If you run into issues the community here will do its best to help.

Hi mdgm, could you kindly PM me a link for 4.x downgrade image. I tried modify the header to "version=6.2.0" but the readynas complains about not being ReadyNas OS image.

Reason for downgrade is because of the USB voltage issue with 6.1.5, I tried 6.1.6 RC3, still the same problem. So I'm trying to downgrade to 4.x then retry R4toR6_6.1.4

Thanks

Thanks again for your help. I successfully downgraded back to 4.x following you instruction with boot menu (got boot menu & front view mixed up), but unfortunately the USB voltage issue is still there with 6.1.4, 6.1.5, 6.1.6 RC3, 6.1.6 RC5. I keep getting "V5_0 voltage in enclosure 'internal' is out of spec. (4,74V)." Same problem another forum member had. On top of that, I also get occasional script error message, and constant drop out with Readycloud/ReadyDrop/ReadyRemote.

Although OS6 seems to be quite a leap with the cloud, but it's still in such infancy stage, virtually no ACL for cloud function and can not merge with local accounts, I'm now back on 4.x. Netgear still got a long way to go.