January 27, 201115 yr I have been running a 12 disk array for over a year. I came home after a weekend, turned on my server (which I hardly ever turn off), logged into the unRaid web server and see that my array is down and all of my drives are labeled as NEW. I haven't messed with this array outside of swapping out bad drives in the past. I have literally done nothing, other than shut it down and turn it back on. It doesn't look like it has any clue of my past raid configuration. If I misalign 2 drives, it doesn't care. I am afraid to do anything. Please... I have years worth of data on this thing. Can anyone provide any guidance or has this happened to anyone before? Thanks, Brandon syslog-2011-01-27_1.txt syslog-2011-01-27_2.txt
January 27, 201115 yr This happened to me once. After rebooting, everything was fine. You can try and scan the USB flash on another computer for errors. Don't forget to safe eject.
January 27, 201115 yr Author I did reboot and nothing changed. I'm afraid to bring it up because i don't want any array info written. When I swap drives around in my settings, normally it tells me, "hey, wrong drive in the wrong spot" Even after a reboot, it could care less. This is why I am afraid to bring it up.
January 27, 201115 yr Your flash drive and the config file on it is likely corrupted. Try as Orbi suggests "You can try and scan the USB flash on another computer for errors. Don't forget to safe eject." From your log file: Jan 27 00:20:42 UNRAIDX emhttp: shcmd (4): modprobe md-mod super=/boot/config/super.dat slots=8,16,8,0,8,144,8,128,8,112,8,48,8,96,8,176,8,192,8,32,8,80,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 >>/var/log/go 2>&1 Jan 27 00:20:42 UNRAIDX kernel: md: unRAID driver 0.95.2 installed Jan 27 00:20:42 UNRAIDX kernel: md: xor using function: pIII_sse (10106.800 MB/sec) Jan 27 00:20:42 UNRAIDX kernel: md: invalid superblock checksum Jan 27 00:20:42 UNRAIDX kernel: md: initializing superblock Jan 27 00:22:24 UNRAIDX emhttp: shcmd (15): rmmod md-mod >>/var/log/go 2>&1 Jan 27 00:22:24 UNRAIDX emhttp: shcmd (16): modprobe md-mod super=/boot/config/super.dat slots=8,16,0,0,8,0,8,128,8,112,8,48,8,96,8,176,8,192,8,32,8,80,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 >>/var/log/go 2>&1 Jan 27 00:22:24 UNRAIDX kernel: md: unRAID driver removed Jan 27 00:22:24 UNRAIDX kernel: md: unRAID driver 0.95.2 installed Jan 27 00:22:24 UNRAIDX kernel: md: xor using function: pIII_sse (10106.800 MB/sec) Jan 27 00:22:24 UNRAIDX kernel: md: invalid superblock checksum Jan 27 00:22:24 UNRAIDX kernel: md: initializing superblock Jan 27 00:22:32 UNRAIDX emhttp: shcmd (17): rmmod md-mod >>/var/log/go 2>&1 Jan 27 00:22:32 UNRAIDX emhttp: shcmd (18): modprobe md-mod super=/boot/config/super.dat slots=8,16,0,0,8,144,8,128,8,112,8,48,8,96,8,176,8,192,8,32,8,80,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 >>/var/log/go 2>&1 Jan 27 00:22:33 UNRAIDX kernel: md: unRAID driver removed Jan 27 00:22:33 UNRAIDX kernel: md: unRAID driver 0.95.2 installed Jan 27 00:22:33 UNRAIDX kernel: md: xor using function: pIII_sse (10106.800 MB/sec) Jan 27 00:22:33 UNRAIDX kernel: md: invalid superblock checksum Jan 27 00:22:33 UNRAIDX kernel: md: initializing superblock Jan 27 00:22:36 UNRAIDX emhttp: shcmd (19): rmmod md-mod >>/var/log/go 2>&1 Jan 27 00:22:36 UNRAIDX emhttp: shcmd (20): modprobe md-mod super=/boot/config/super.dat slots=8,16,8,0,8,144,8,128,8,112,8,48,8,96,8,176,8,192,8,32,8,80,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 >>/var/log/go 2>&1 Jan 27 00:22:36 UNRAIDX kernel: md: unRAID driver removed Jan 27 00:22:36 UNRAIDX kernel: md: unRAID driver 0.95.2 installed Jan 27 00:22:36 UNRAIDX kernel: md: xor using function: pIII_sse (10106.400 MB/sec) Jan 27 00:22:36 UNRAIDX kernel: md: invalid superblock checksum Jan 27 00:22:36 UNRAIDX kernel: md: initializing superblock
January 27, 201115 yr Author I scanned the drive and it found no issues. My .cfg files all look okay to me. I still haven't turned the array on for fear of ruining data by overwriting. What measures would any of you take to solve this problem. Also, if USB key was dead and I have no backup of my config files, is my file structure lost? /beg /pray
January 27, 201115 yr No. File structure is saved in the MBR on each hard drive. Among other things, the .cfg files are there to remember which disk is disk1 and disk2, etc. The hard drive without partition is your parity. How to reassign the remaining hard drives correctly, I'm not sure. Did you ever take a screenshot of the management web page?
January 27, 201115 yr It is most important that your parity disk be assigned to the parity slot. If other disks are not assigned in the right order, not as big a deal although your user share configs may not work as well. If you have a cache or non-array disk, make sure neither are assigned to disk slots. Look in the wiki for the "trust my array" procedure. It can put your configuration back in place without rebuilding parity. But be 100% sure about your parity disk. All disks including parity contain a partition. Next step would be to shutdown and reboot and see if the config is saving properly. If not you might need to replace the USB drive with a new one. Tom is pretty understanding and will generate a new key for you without cost.
January 27, 201115 yr Your disk configuration is shown in the syslog you posted. It shows one of the Hitachi drives as your parity drive. (disk0 is the parity drive) UNRAIDX kernel: md: import disk0: [8,16] (sdb) Hitachi HDS722020ALA330 JK1121YAG20MRS offset: 63 size: 1953514552 UNRAIDX kernel: md: import disk1: [8,0] (sda) Hitachi HDS722020ALA330 JK11A1YAJ84KNV offset: 63 size: 1953514552 UNRAIDX kernel: md: import disk2: [8,144] (sdj) SAMSUNG HD103UJ S1FXJ1KQ800003 offset: 63 size: 976762552 UNRAIDX kernel: md: import disk3: [8,128] (sdi) ST3750640AS 3QD0D98X offset: 63 size: 732574552 UNRAIDX kernel: md: import disk4: [8,112] (sdh) ST3750640AS 5QD3SKJ9 offset: 63 size: 732573496 UNRAIDX kernel: md: import disk5: [8,48] (sdd) ST31500341AS 6VS061W2 offset: 63 size: 1465138552 UNRAIDX kernel: md: import disk6: [8,96] (sdg) ST3750640AS 5QD3BHJP offset: 63 size: 732573496 UNRAIDX kernel: md: import disk7: [8,176] (sdl) ST3500630AS 9QG7H0HV offset: 63 size: 488386552 UNRAIDX kernel: md: import disk8: [8,192] (sdm) ST3500630AS 9QG3JJ74 offset: 63 size: 488386552 UNRAIDX kernel: md: import disk9: [8,32] (sdc) Hitachi HDS722020ALA330 JK1170YAH1ZUPP offset: 63 size: 1953514552 UNRAIDX kernel: md: import disk10: [8,80] (sdf) ST3500630AS 9QG2LPVR offset: 63 size: 488386552 The internal checksum in the config/super.dat file is incorrect. It is not being trusted. It might be the array was not powered off cleanly, it might be the flash drive is wearing out, OR, ir might be you have defective or mis-configured RAM and the calculated checksum was incorrectly calculated. You said you ran scandisk on the flash drive and it is good. Good first step. Next, run a memory test for several passes, or overnight if possible. The, you can use the "trust my parity" procedure as described in the wiki to rebuild you super.dat file. The data on your data disks is not affected by the procedure as long as the parity disk is assigned to the parity slot in the array. Joe L.
January 27, 201115 yr Author Thank you very much Joe and others for the advise. This decades worth data is important enough for me that I would have to go purchase 10TB worth of HDDs and manually back my data up on each drive before attempting anything if I don't have your confidence that if will correct itself. That would be very expensive and tedious. If it is what I need to do before doing all this, then I will. I do have a alot questions before attempting anything. I will do my best to detail them below. I also highlighted them. I am already running memtests on my ram while I'm at work, but i suspect that this occurred because of an unclean shutdown. I'm pretty confident that my drives are assigned correctly and that disk0 is my parity. My confidence is not brave enough to attempt this trust my parity procedure without some professional advise. Is there a way for me to prove disk0 is my parity? Can I pull the other 2TB drives and check them for personal data on another machine to prove my parity is correct? Would it be bad if I hooked my parity up to a windows machine? What would you do? What scares me the most about all this is... in unraid and unmenu, both show all my drives as new and all disks as completely empty. I have not started the array at all, so they may have not had a chance to read the disks either. Is this expected, normal behavior? The trust my parity procedure seems to fit the bill. I am a bit confused though. It looks like multiple options, but also looks like a an ordered procedure. Open a console, either at the unRAID server or in a Telnet or PuTTY window. Make sure you are in the home directory, which is /root. If you are unsure, type cd and press the Enter key, and you will be there. Boot unRAID, but DO NOT START the array. Stop the array if it has started. DONE Make sure that all of your disks are correctly assigned, not disabled or missing. Note: they do not have to be assigned to the same slots they were originally assigned to, except for the Parity drive(!), but it MUST be the same set of drives. Working on verifying this info now. If you are running any version of unRAID that is PRIOR to v4.5.4, then at the unRAID Web Management page, click the Restore button, after first checking the "I'm sure I want to do this" box. I'm running 4.6beta5, So I assume I skip this procedure. The restore button scares the hell out of me, should it? If you are running unRAID version v4.5.4 or later, then log in as root at your system console or via telnet and type the following command: initconfig On the unRAID Web Management Main page, this should result in all disk status symbols/balls turning <Blue>. The server status should indicate "Stopped. Initial Configuration" My disks were blue before I started this procedure? Did I even need to do the above? Now at the unRAID console or Telnet or PuTTY prompt, type this command: mdcmd set invalidslot 99 What does this do? The output of this command should be this: cmdOper=set , cmdResult=ok Now click the Start button. All the disk status indicators should turn <Green>; the system state should be Started; and there should be a parity check in progress. You can let the parity check complete, or you can cancel it. In most cases, you should let it finish. If you were correct and parity was valid, the parity check will not find any errors. If you were wrong, then the parity check will find and correct the errors, and report them. By the time the parity check reports on the parity errors, they will have already been corrected. Is there any reason I can't do this right now if my array is stopped, my drives are in the correct slot and they are all blue? I appreciate the help in advance.
January 27, 201115 yr Thank you very much Joe and others for the advise. This decades worth data is important enough for me that I would have to go purchase 10TB worth of HDDs and manually back my data up on each drive before attempting anything if I don't have your confidence that if will correct itself. That would be very expensive and tedious. If it is what I need to do before doing all this, then I will. I do have a alot questions before attempting anything. I will do my best to detail them below. I also highlighted them. I am already running memtests on my ram while I'm at work, but i suspect that this occurred because of an unclean shutdown. I'm pretty confident that my drives are assigned correctly and that disk0 is my parity. My confidence is not brave enough to attempt this trust my parity procedure without some professional advise. Is there a way for me to prove disk0 is my parity? Can I pull the other 2TB drives and check them for personal data on another machine to prove my parity is correct? Would it be bad if I hooked my parity up to a windows machine? What would you do? What scares me the most about all this is... in unraid and unmenu, both show all my drives as new and all disks as completely empty. I have not started the array at all, so they may have not had a chance to read the disks either. Is this expected, normal behavior? It is because they have not yet been mounted. It is expected. The trust my parity procedure seems to fit the bill. I am a bit confused though. It looks like multiple options, but also looks like a an ordered procedure. It is an ordered procedure. The one difference is how you set a new initial disk configuration. On older releases it was the button poorly labeled as "Restore". In newer releases, it is a command line command named "initconfig" You do not have to guess which of your disks is the parity disk. You disk configuration file in the config folder is correctly associating it with the parity slot in the array. the config/super.dat file has the corruption. It has an internal checksum that is invalid. It needs to be re-built by unRAID. You can do that by typing initconfig while the array is stopped. The initconfig command will ask you to respond with "Yes" if you are sure you want a new configuration. Respond to the prompt with "Yes" (Capital "Y" and lower case "es") This "initconfig" command will not erase your data disks or change them in any way. It will specifically rename the existing config/super.dat file to config/super.old so it will not be detected when you next start the array. Normally, when you first start an array for the very first time, disk0 (parity) is not valid. There is not valid parity information in it. This is not the case for you. You have a valid parity drive with valid parity calculations. When you refresh the web-management page in the browser it will say something like: "Start will record all disk information, bring the array on-line, and start Parity-Sync" This is because the parity disk internally is marked as not being "valid" (not having valid data) If you force a non-existent disk to be invalid instead, a parity check will be performed instead of an initial parity sync. That is what the /root/mdcmd set invalidslot 99 does. It sets the invalid slot to be disk 99, a disk that does not exist in any array. Open a console, either at the unRAID server or in a Telnet or PuTTY window. Make sure you are in the home directory, which is /root. If you are unsure, type cd and press the Enter key, and you will be there. Boot unRAID, but DO NOT START the array. Stop the array if it has started. DONE Make sure that all of your disks are correctly assigned, not disabled or missing. Note: they do not have to be assigned to the same slots they were originally assigned to, except for the Parity drive(!), but it MUST be the same set of drives. Working on verifying this info now. Because your disk.conf file was fine, the disks are already in their correct spots in the array assignment. If you are running any version of unRAID that is PRIOR to v4.5.4, then at the unRAID Web Management page, click the Restore button, after first checking the "I'm sure I want to do this" box. I'm running 4.6beta5, So I assume I skip this procedure. The restore button scares the hell out of me, should it?If you are running unRAID version v4.5.4 or later, then log in as root at your system console or via telnet and type the following command: initconfigOn the unRAID Web Management Main page, this should result in all disk status symbols/balls turning <Blue>. The server status should indicate "Stopped. Initial Configuration" My disks were blue before I started this procedure? Did I even need to do the above? Yes, you need to set a new configuration to force the creation of a new config/super.dat file and so the web-maagement console knows it is to treat the array as a new config, not one where it will clear the disks before use. Look specifically for the wording I described on the web-managemet console before you press "Start". If when refreshing the screen it mentions anythinng about clearing drives, like this: " All new disks which have not been factory-erased will be cleared first;" DO NOT START THE ARRAY. Now at the unRAID console or Telnet or PuTTY prompt, type this command: mdcmd set invalidslot 99 What does this do? Described above. The output of this command should be this: cmdOper=set , cmdResult=okNow click the Start button. All the disk status indicators should turn <Green>; the system state should be Started; and there should be a parity check in progress. You can let the parity check complete, or you can cancel it. In most cases, you should let it finish. If you were correct and parity was valid, the parity check will not find any errors. If you were wrong, then the parity check will find and correct the errors, and report them. By the time the parity check reports on the parity errors, they will have already been corrected. Is there any reason I can't do this right now if my array is stopped, my drives are in the correct slot and they are all blue? Yes, you did not tell unRAID it is a new array so it might want to start fresh and clear the disks. I would follow the procedure by typing "initconfig" and go from there. I appreciate the help in advance. You are welcome.
January 27, 201115 yr Author Joe, The detail and time you put into this issue is very much appreciated. Thank you for answering all my questions. I will follow up with my results.
Archived
This topic is now archived and is closed to further replies.