Dashboard opens with blank only

[Mijzelf]

By "clean" you mean empty? So, all previous data is lost, and there is nothing left to solve that?

No, by clean he means healthy. The raid array is fine, unfortunately that says nothing about the contained filesystem. But it doesn't make sense to recreate the array.

I think it is not empty, you reported this

Code: Select all

root@fvdw-sta-kirkwood:/ # mdadm -D /dev/md4
/dev/md4:
        Version : 1.2
  Creation Time : Thu Jan  1 01:15:34 1970
     Raid Level : raid5
     Array Size : 7805490688 (7443.90 GiB 7992.82 GB)
  Used Dev Size : 1951372672 (1860.97 GiB 1998.21 GB)
   Raid Devices : 5
  Total Devices : 5
    Persistence : Superblock is persistent


so about 1.7 TB used of the 7.3

How could mdadm know about the used space in the contained filesystem? The 'Used Dev Size' is the size of a single member of the 5 disk raid5 array.

PhotoRec indeed doesn't need the filesystem. There are a number of problems, however. It won't give any metadata (filename, path, timestamps) as they are part of the filesystem. Further it cannot see if a file was deleted (for the same reason), and on a fragmented filesystem it can output corrupted files, or fail to restore a fragmented file. It can only find files with a recognizable header or footer. And last but not least, you'll have to have the possibility to assemble the array on the system running PhotoReq, which means you can connect at least 4 disks. Or run PhotoReq on the NAS itself. Or dump the whole 8TB array to a single extern disk.

@fariaslcfs: Did anything happen which made you reset the NAS? If yes, what?

[fariaslcfs]

@Mijzelf

Probably I power failure caused the NAS to get stuck in this situation. I tried to execute a nondestructive reset, but the procedure did not work properly. I described what happened in the previous posts (https://plugout.net/viewtopic.php?f=26&t=3472#p34808).

Tks friend.

[fariaslcfs]

Code: Select all

.........................................................
found candidate secondary superblock
unable to verify superblock, continuing...
.........................................................

The output above was seen more than one time while executing the command:

Code: Select all

xfs_repair /dev/md4

[Mijzelf]

Can you assemble & mount the raid array formed by /dev/sd[abcde]8? It might be possible to inject a telnet daemon in the firmware, to see if the Lacie kernel can mount that data partition.

[fariaslcfs]

Can you assemble & mount the raid array formed by /dev/sd[abcde]8? It might be possible to inject a telnet daemon in the firmware, to see if the Lacie kernel can mount that data partition.

Yes, but only tomorrow morning.
However, changes in the server firmware may be associated with data loss risks, aren't they?

[fvdw]

@mijzelf
I have a linux 3.9.5 standalone kernel as well, would this be worth a try if that kernel can mount the array? (it has nwsp2 in the name but it also supports the 5big2)

It will need some extra commands in the telnet client to upload the mini glibc and tools as fvdw-sl-programs is not included in that kernel.

[Mijzelf]

However, changes in the server firmware may be associated with data loss risks, aren't they?

More data loss than you are facing now, you mean?

The server firmware is a full blown Linux system. All we do is adding a start script for the already installed telnet daemon. (That is, I hope it is installed. It is on the 2Big2 2.5.6.3 firmware).

@mijzelf
I have a linux 3.9.5 standalone kernel as well, would this be worth a try if that kernel can mount the array?

It won't hurt.

/Edit: In case I'm not here, to get telnetd running next changes have to be made:

Add a file telnetd.i to <mountpoint-of-array>/etc/initng/:

Code: Select all

#!/sbin/itype
daemon telnetd {
   need = virtual/net;
   exec daemon = /usr/sbin/telnetd -l /bin/sh ;
   forks;
   daemon_stops_badly;
}

and add a line 'telnetd' to <mountpoint-of-array>/etc/initng/runlevel/default.runlevel:

Code: Select all

echo telnetd >> <mountpoint-of-array>/etc/initng/runlevel/default.runlevel


[fvdw]

attached standalone kernel based on linux 3.9.5
Unzip the archive and put the file in the tftp folder of the fvdw-sl-console
Select it when loading the standalone kernel with fvdw-sl-console

In telnet client give this command to get and run the fvdw-sl-programs to upload mini glibc and tools

replace ip-pc by the ip of your pc running the console

Code: Select all

cd /
tftp -r fvdw-sl-programs.sh -l fvdw-sl-programs.sh -g ip-pc

Code: Select all

chmod 755 fvdw-sl-programs.sh
/fvdw-sl-programs.sh

[fariaslcfs]

Thanks! Will do as instructed tomorrow morning.
After that, should I assemble & mount the raid array formed by /dev/sd[abcde]8 as devised by @Mijzelf?

[fvdw]

If the 3.9.5 kernel also cannot mount the array, then yes.
In principle adding telnet or ssh server should not affect the raid array with your data as that is on different partitions