nexusmaniac Posted September 3, 2018 Share Posted September 3, 2018 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 Quote Link to comment
nexusmaniac Posted September 3, 2018 Author Share Posted September 3, 2018 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?? Quote Link to comment
nexusmaniac Posted September 3, 2018 Author Share Posted September 3, 2018 Sh†t .. I should not have set SDF as parity 😭😭 It began a parity rebuild 😭 what the hell!! 😱😖 Quote Link to comment
trurl Posted September 3, 2018 Share Posted September 3, 2018 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??? Quote Link to comment
trurl Posted September 3, 2018 Share Posted September 3, 2018 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? Quote Link to comment
nexusmaniac Posted September 3, 2018 Author Share Posted September 3, 2018 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 Quote Link to comment
nexusmaniac Posted September 3, 2018 Author Share Posted September 3, 2018 Only diagnostics would've been attachments to previous threads on the forum Quote Link to comment
nexusmaniac Posted September 3, 2018 Author Share Posted September 3, 2018 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? Quote Link to comment
trurl Posted September 3, 2018 Share Posted September 3, 2018 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 Quote Link to comment
trurl Posted September 3, 2018 Share Posted September 3, 2018 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 Quote Link to comment
nexusmaniac Posted September 3, 2018 Author Share Posted September 3, 2018 Just now, trurl said: old attachments didn't make it over to the new forum Didn't think they did, damn Quote Link to comment
trurl Posted September 3, 2018 Share Posted September 3, 2018 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. Quote Link to comment
nexusmaniac Posted September 3, 2018 Author Share Posted September 3, 2018 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" ? Quote Link to comment
trurl Posted September 3, 2018 Share Posted September 3, 2018 Please don't do anything else at all until further advice. I am working on a response. 1 1 Quote Link to comment
trurl Posted September 3, 2018 Share Posted September 3, 2018 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. 1 Quote Link to comment
nexusmaniac Posted September 3, 2018 Author Share Posted September 3, 2018 HOLY BALLS! I do!! raptor-diagnostics-20180714-1318.zip Quote Link to comment
nexusmaniac Posted September 3, 2018 Author Share Posted September 3, 2018 It was in the USB backup dir... Bloody hell that was lucky, I had it nowhere else whatsoever Quote Link to comment
nexusmaniac Posted September 3, 2018 Author Share Posted September 3, 2018 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 Quote Link to comment
itimpi Posted September 3, 2018 Share Posted September 3, 2018 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. 1 1 Quote Link to comment
trurl Posted September 4, 2018 Share Posted September 4, 2018 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. 1 Quote Link to comment
Squid Posted September 4, 2018 Share Posted September 4, 2018 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 itselfSent from my SM-T560NU using Tapatalk 1 Quote Link to comment
trurl Posted September 4, 2018 Share Posted September 4, 2018 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 1 Quote Link to comment
nexusmaniac Posted September 4, 2018 Author Share Posted September 4, 2018 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. Quote Link to comment
JorgeB Posted September 4, 2018 Share Posted September 4, 2018 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 Quote Link to comment
nexusmaniac Posted September 4, 2018 Author Share Posted September 4, 2018 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... Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.