Lacie 5Big2 Failed After Firmware Update

[unlucky1]

But it worked before the firmware update...

[fvdw]

GUID is stored in GPT partiton table in primary header

http://en.wikipedia.org/wiki/GUID_Partition_Table

[fvdw]

we can change the GUID
in gdisk (for instance for /dev/sdc) give commands
x (to enter expert mode)
then use command g to modify the GUID (change one number or letter)
after that enter command w to write the new table to disk

then try again what mdadm examine says

[unlucky1]

Should I randomize?

Code: Select all

root@(none):/ # gdisk /dev/sdc
GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): x

Expert command (? for help): g
Enter the disk's unique GUID ('R' to randomize):

[unlucky1]

Afterwards, should I re.write the table?

[fvdw]

yes I see no problem for that we can always restore the old value as we have on the forum in your posts

yes you should enter "w" 9without the quotes to write it to the partition table

[Mijzelf]

The question about 5 disks was for fvdw. I want to know if this kernel has proven to be able to handle 5 disks.

The question about the nature of your data is about data recovery. At the moment it seems at least sdb2 and sdc2 don't have a valid raid header. Those header are at the end of the partition (and in this case also of the disk). The partition table (at the beginning of the disk) was also damaged, so I suppose we should prepare for the possibility that the in-between data is also not completely healthy.
Low-level recovery (recovery without the possibility to use file system data) is only doable on data with recognizable structures, like photos and video's.

Is this your original 5big2, or your new one? If fvdw is right about that the diskid should not be the same, maybe we are looking at a hardware problem.

[unlucky1]

Okay, made a new ID...

Code: Select all

Expert command (? for help): g
Enter the disk's unique GUID ('R' to randomize): R
The new disk GUID is 00000000-943E-0400-1835-0A000145C1BE

Expert command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sdc.
The operation has completed successfully.
root@(none):/ # mdadm --examine /dev/sdc2
mdadm: No md superblock detected on /dev/sdc2.

[unlucky1]

Code: Select all

root@(none):/ # gdisk /dev/sdc
GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y

Command (? for help): n
Partition number (1-128, default 1): 2
First sector (34-1953525134, default = 2048) or {+-}size{KMGTP}: 4048896
Last sector (4048896-1953525134, default = 1953525134) or {+-}size{KMGTP}: 1953523711
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sdc.
The operation has completed successfully.
root@(none):/ # mdadm --examine /dev/sdc2
mdadm: No md superblock detected on /dev/sdc2.


[fvdw]

The question about 5 disks was for fvdw. I want to know if this kernel has proven to be able to handle 5 disks.

I personally never used the kernel on a 5big2 with 5 disks, but I see no reason why it should not be able to do that.
Another user has used it on 5big2 (Draftmancorp) with all disks installed and it worked without a problem to detect its 5 disks and access them