Lacie 5Big2 Failed After Firmware Update

[Mijzelf]

There has been some posts meanwhile. This was an answer on fvdw thinking if sde2 could be active device 3.

unlucky1 has moved this disks from nas1 to nas2 (and back?) and we have some strange name-mangling, so I think it's not really predictable which 'active device' sde2 should be.
Anyway, it doesn't matter. Each raid member has it's role written in it's metadata. You can exchange disks, and still the array can be assembled.

I think it's a good idea to exchange disks, so that sdb and sdc are in a slot which now contains a healty raid member, to see if the problem is slot-related. Problem is that I'm tired, and cannot think about which physical disks that are (name mangling)
For the moment I'm stopping, I need some sleep.

[unlucky1]

Did you go to bed? It's pretty late... shall we continue tomorrow?

[fvdw]

So you think sdc is broken?

well the disk seems to be functional but it doesn't sems to have the raid header and also sdb seems to have that problem
if two disk missing this info means that it can not rebuild the array well then we have an issue.
I still would not give up as we don't know if the partition are erased or not. The data could still be there.
maybe it is possible to restore the raid header using the ones present on the good disks ??? Mijzelf may be able to tell more about that.
For this evening i need to go to bed as tomorrow there is working day for me.

to be continued.

ps1 are you sure that the disk are in the right order ?
ps do let the 5big2 boot the lacie firmware for the moment, if this the disk less version of the 5big2 it might see that as a new install and wipe/format all your disks.

[fvdw]

see you tomorrow, good night

[unlucky1]

Thanks for all your help today!!! I really have some hope now! I will not boot the Lacie disk with Lacie firmware until we are ready! The disks are most likely all in the right order but I will shut down and verify (I numbered them when inserting so i can be sure).

Thanks again and work with you again tomorrow!

[fvdw]

after a night of sleep some ideas and thoughts

why would a firmware upgrade destroy a raid array and why only disk 2 and 3:scratch
Could this be because sda8 and sda9 are in a raid array as Mijzelf told ? those will be overwritten (adapated) in a firmware upgrade
Not that it will help a lot if this is the cause :dry

About datat partitions
Mijzelf wrote this

..... the raid header is at the end of the partition.

if so then we could try to read the last sectors of the partition using dd with offset or define a loop device pointing at the last sectors of the partition, mount the loop device and and use then the dd command to extract the data from those sectors and put it in a file. This then can be uploaded to the remote pc using tftp server.
We could look at it this "header" (modify it) and put it back. Or copy one from a good disk, modify that to make it suitable for the respective member.
An issue will be if sdb was member 2 and sdc member 5 or the other way around...

But as said earlier my knowledge of raid is low so maybe I look a little to simple to this issue

To rule out a hardware problem we could swap disk in slot 3 (sdc) with the one in slot5 (sde) and see if the problem moves with the disk.
Of course only if this doesn't harm the data on the disks

Before doing anything we should think twice if it won't affect the data on the disks.

ps during daytime I have very little time because my normal work, sorry for this.

[unlucky1]

Well, I've been way over my head for a while so I am really grateful for as far as you've gotten me! As you said, if we can get 4 disks, we can build the array and move the data. And we're closer than Lacie ever even tried. I'll search the net a bit as well and see how a raid stores its info to disk but as I said, I'm really out of my element here so I really need you 2 to help me. And any time you can find for me is great!

[Mijzelf]

Good morning everybody. Had a good sleep?

After googling a bit, it seems assembling might be as simple as

Code: Select all

mdadm --assemble /dev/md0 --uuid=4f4a8ea3:4c99b769:e18e6826:872bc27f

mdadm is supposed to search all blockdevices for a valid raidheader containing this uuid, and assemble the array. It is important that the disks are in the right sequence.

I wonder if it's a good idea to try another mdadm too. This one is stripped a bit, and I don't know if that matters. I'll look if I can extract the one from the Lacie initrd.

/Edit: added the mdadm+libs. Extract it in the root of the filesystem.

[unlucky1]

I shut down the system to check that the disks are in the right order. I'll check and then I will get the system going again and tftp the files over and let you know. Should I try running that command then once it's up and ready or not yet? Also, you say put it in the rot of the filesystem, you mean to tftp it over to Lacie and leave it in that root?

[Mijzelf]

You should put the file in the root, and extract it:

Code: Select all

tar xzf mdadm.tgz

This should generate a /sbin/mdadm, en some files in /lib.

And then you can run

Code: Select all

mdadm --examine /dev/sd[abcde]2

to see if it performs better than the stripped version.