I messed around with ACS, tried to separate out a GPU for a VM, gave up. 

 

So I disabled the ACS override and rebooted. My USB was wiped clean!!

 

I reimaged it with 6.6.0 and started my array again to grab a backup of my USB (1st Sept. 2018) so I could restore it.

That was fine, I grabbed the USB backup folder.

 

I copied all the files to my USB and booted up. 

 

Bottom left told me "Array Stopped STALE CONFIGURATION" I've no bloody clue what to do

 

I started the array with the below disks, I daredn't put a parity in in case it wipes a data disk - but I don't KNOW the assignments of my disks tbh. I thought it was sdf, g, h, i & j (parity, 1, 2, etc.) but when I mount these disks sdi is unmountable, no filesystem. Could that be my parity?

 

I'm really unsure what to do / where to go from here! Hoping for some help please

 

#scary

 

This is what happens when I hit start: I believe I should try to use sdf as my parity and restart the array??

 

Then hopefully restore data on disk3? But I don't know for sure so I don't want to risk doing anything.

 

They are BTRFS disks - should I scrub Disk3??

 

Sh†t .. I should not have set SDF as parity 😭😭

 

It began a parity rebuild 😭 what the hell!! 😱😖

Obviously relying on flash backup that is stored on the array is a bad idea. For future reference you can download a zipped copy of your flash at anytime simply by going to Main - Boot Device - Flash - Flash Backup. It will download the zipped contents of your flash to the usual location your browser downloads files, somewhere on your PC and not on the array.

 

Also, you should always get a backup of your flash anytime you make any configuration change, but especially anytime you make any disk changes.

 

Do you have any recent diagnostics from before this? If so we can look at them and see what your disk assignments should be.

 

Otherwise, the usual advice is to assign all disks to the array and none to parity. Hopefully you will only have one unmountable (if single parity) and that disk would be the one you should assign to parity. Based on that idea I would guess that the disk you have assigned as disk3 is actually your parity.

 

Don't do anything without further advice.

 

Oh well, I guess I couldn't type fast enough. Why didn't you wait just a few minutes for help since you obviously didn't know what to do???

 

 

At this point I would assume you have lost all data on the former disk3 by assigning it as parity. The unmountable disk you have assigned as disk3 will be no help and will never be mountable since it was parity and parity has no filesystem to mount.

 

Do you have backups of any important and irreplaceable files?

I'm an idiot that's why

 

Err... So IF I do a 'new config' and assign disk 3 to parity and then put the other disks into the array as normal will it be possible to recove

Only diagnostics would've been attachments to previous threads on the forum

Crap, that won't work  

Warning is literally right there...

 

Err ok, so @trurl if I put my flash drive back to the state it was in 20 mins ago (stale config) and set disk 3 ... (/dev/sdi) as the parity, and all other disks in the array as normal, putting /dev/sdf as my disk3, then start the array - will that work?

 

3 minutes ago, nexusmaniac said:

I'm an idiot that's why

 

Err... So IF I do a 'new config' and assign disk 3 to parity and then put the other disks into the array as normal will it be possible to recove

no

3 minutes ago, nexusmaniac said:

Only diagnostics would've been attachments to previous threads on the forum

old attachments didn't make it over to the new forum

Just now, trurl said:

old attachments didn't make it over to the new forum

Didn't think they did, damn

1 minute ago, nexusmaniac said:

Crap, that won't work  

Warning is literally right there...

 

Err ok, so @trurl if I put my flash drive back to the state it was in 20 mins ago (stale config) and set disk 3 ... (/dev/sdi) as the parity, and all other disks in the array as normal, putting /dev/sdf as my disk3, then start the array - will that work?

 

 

No.

 

8 minutes ago, trurl said:

Do you have backups of any important and irreplaceable files?

Parity isn't a substitute for backup as you have seen.

Array currently looks like this, I didn't 'break' my parity drive by putting the wrong disk into the parity slot. 

 

The parity still exists in some capacity - Should be possible to get sdi into the parity slot, right? And treat sdf as a 'new' disk that is missing the data which is housed on the parity disk (sdi)

 

sdi = parity

sdg = d1

sdh = d2

sdf = d3

sdj = d4

 

Still "no" ? 

 

 

Please don't do anything else at all until further advice. I am working on a response.

Your idea is to go back in time to the "flash backup" from before you made the mistake of starting the array with the wrong disk as parity.

 

I think you are close. If you redo the disk assignments as you say, the main thing we want to avoid is having it rebuild parity when you start. We need it to rebuild disk3 instead.

 

Instead of going back to the "flash backup", it might be a better idea to just New Config from here with the correct assignments and tell it parity is already valid, then make it rebuild disk3.

 

Are you sure you don't have a copy of recent diagnostics? You must have downloaded them somewhere before posting to the forum. I would feel a lot better about this if we could verify the correct assignments.

 

I have to be away for a few hours now. I am going to tag @johnnie.black to help you proceed with this. Maybe he or someone else will get involved before I get back.

 

Don't do anything without further advice.

HOLY BALLS! I do!!

 

raptor-diagnostics-20180714-1318.zip

 

It was in the USB backup dir... Bloody hell that was lucky, I had it nowhere else whatsoever

And here's one fresh diagnostics zip to compare

 

Any chance that dinking around with ACS override (on & off) could've messed with the linux disk assignments in some way? I know they're not fixed so it's not a guarantee that sdf will always be 'sdf' etc.

 

raptor-diagnostics-20180903-2332.zip

8 minutes ago, nexusmaniac said:

Any chance that dinking around with ACS override (on & off) could've messed with the linux disk assignments in some way? I know they're not fixed so it's not a guarantee that sdf will always be 'sdf' etc

You should never make assumptions about the sdX type device names as they are always potentially subject to change as they are assigned dynamically as Linux is booting so anything that can cause timing to change in any way can result in different values being assigned to a given disk.   Even though they rarely change if you are going to take any action using that type of device name you always should be checking what the values are for a particular disk for THIS boot.

According to your 0714 diagnostics you did indeed assign parity to disk3 and disk3 to parity. I hope you have learned some patience.

 

unRAID identifies the disk assignments according to the disk serial number, not where it is in the case (obviously it doesn't know), what port it is connected to, or which disk Linux assigns as sdwhatever

 

Here are the correct disk assignments, last 4 characters of serial number, according to that diagnostic:

 

disk0: JC2L (parity)
disk1: KFHU
disk2: 2T4R
disk3: 9H09
disk4: E067
cache: 0354
cache: 0302
 

Go to Tools - New Config - Retain All, then change any assignments you need to match above. Do not start the array. Post a screenshot of the assignments before doing anything else. Include a screenshot of the Array Operations section of Main.

To expand on what@trurl stated, the sdX identifier can change from boot to boot, and should never be relied upon as the designator of which disk is which. Always use the serial number of the drive itself

Sent from my SM-T560NU using Tapatalk

Since there isn't as much activity now I was just reviewing this thread and noticed this misconception:

4 hours ago, nexusmaniac said:

treat sdf as a 'new' disk that is missing the data which is housed on the parity disk (sdi)

The parity disk does not contain any of your data. How could it? It doesn't have the capacity to contain all of the data for all of the array disks.

 

Parity just contains bits that in combination with bits from ALL of the other disks allow the missing data to be calculated. The parity calculation isn't very complicated. Here is a wiki:

 

https://wiki.unraid.net/UnRAID_6/Overview#Parity-Protected_Array

 

5 hours ago, trurl said:

According to your 0714 diagnostics you did indeed assign parity to disk3 and disk3 to parity. I hope you have learned some patience.

 

unRAID identifies the disk assignments according to the disk serial number, not where it is in the case (obviously it doesn't know), what port it is connected to, or which disk Linux assigns as sdwhatever

 

Here are the correct disk assignments, last 4 characters of serial number, according to that diagnostic:

 

disk0: JC2L (parity)
disk1: KFHU
disk2: 2T4R
disk3: 9H09
disk4: E067
cache: 0354
cache: 0302
 

Go to Tools - New Config - Retain All, then change any assignments you need to match above. Do not start the array. Post a screenshot of the assignments before doing anything else. Include a screenshot of the Array Operations section of Main.

 

Ok thank you ever so much - I do apologise for being so impatient...

 

Just to clarify, I should hit "apply" now?

 

 

5 hours ago, Squid said:

To expand on what@trurl stated, the sdX identifier can change from boot to boot, and should never be relied upon as the designator of which disk is which. Always use the serial number of the drive itself

Sent from my SM-T560NU using Tapatalk
 

 

Indeed, I know it can be dynamic but had assumed that (based on years of using *nix based systems) the drive letters would remain constant if they were plugged into the same port, which all of my disks have. I now know that that assumption is wildly inaccurate.

 

3 hours ago, trurl said:

Since there isn't as much activity now I was just reviewing this thread and noticed this misconception:

The parity disk does not contain any of your data. How could it? It doesn't have the capacity to contain all of the data for all of the array disks.

 

Parity just contains bits that in combination with bits from ALL of the other disks allow the missing data to be calculated. The parity calculation isn't very complicated. Here is a wiki:

 

https://wiki.unraid.net/UnRAID_6/Overview#Parity-Protected_Array

 

 

Yeah, GMT - it was late for me 

To clarify the point I was attempting to make; by 'data' I meant the parity data needed to recalculate what data is missing from my array. I with the rest of the array constant, I should be able to take the working parity drive and (with a 'new' disk3) be able to get my missing data back. Based on the XOR calculation that the parity drive stores.

I know how the parity calculation works  I was rushed, panicked and tired last night - hence my rushing around etc.

 

You should still be able to rebuild disk3 using the invalid slot command, though not tested yet on v6.6, but should work the same.

 

-Tools -> New Config -> Retain current configuration: All -> Apply
-Check all disks are assigned in the correct positions.
-Important - After checking the assignments leave the browser on that page, the "Main" page.

-Open an SSH session/use the console and type:

mdcmd set invalidslot 3 29

 

-Back on the GUI and without refreshing the page, just start the array, do not check the "parity is already valid" box, disk3 will start rebuilding, disk should mount immediately but if it's unmountable don't format, wait for the rebuild to finish and then run a filesystem check

Hi @johnnie.black I've done new config, retain all and hit Apply. I've also put my disks back in the right order as determined by @trurl

 

 

I'm not going to hit anything until somebody says what, hoping to recover disk3

 

That red error message is terrifying...