I am running 4.3.3 and had a disk fail on me today.  (Actually it didn't quite fail, but was dumping resets and such into the syslog and I decided to replace it).

 

I did a clean shutdown, inserted a new disk, and booted up.  On bootup there were two missing disks (the bad one and another one).  I shut down and found that I had accidently unplugged one of my drives.  I plugged it back in.

 

On reboot the other disk is back and only the failed disk showing as missing.  (I expected it would have automagically assigned the new disk to the missing slot, but it didn't).  I manually switched it out for the new one on the devices page, but unRAID is still showing "Invalid Configuration" and next to the start button is says "Too many wrong and/or missing disks.  There is no option to start the array.  All the other disks are showing properly assigned to the right slots.

 

I think I need to unassign the failed device from the failed slot, and reboot, but this was confusing enough that I thought I would post and get a definitive answer.  I think others might someday encounter this situation.

 

What do I need to do to get the new disk to turn blue so it will rebuild?

 

Thanks

I think you will need to plug back in the drive you were going to replace so it can figure out it has only one missing drive. (the one you accidentally unplugged)  This is by far the safest approach.  Your array thinks it has two failed disks. (or rather, one missing, one different)

 

The only other way to force it to think the array is sane would be to use the "/root/mdcmd set invalid slot NN" 

command after pressing "restore" and before pressing "Start" to force it to think the disk you replaced is the one to be rebuilt. (where NN = the slot number of disk you wish to rebuild) 

 

I've never read of anybody doing this, but I'm pretty sure it would do what you wanted.  It might warrant an e-mail to Tom.

 

Another possibility, If you had made a copy of the "config/super.dat" file, before you did any part of this, you could just copy it back and you would probably also be ok.

Hmmm ... Something is wrong.

 

I did what you suggested - put the other disk back in (i really don't think there is anything wrong with it, but I want to replace it for other reasons).

 

I got the configuration "valid" again.

 

Started the array - no problem.

 

Stopped the array.

 

Unassigned the disk I want to replace.

 

Rebooted.

 

Same thing.  Invalid configuration.  Too many wrong and/or missing disks!

 

Syslog?

 

Was Disk 11 the one that previously was unplugged?  Are you absolutely sure it is now OK?

It was NOT disk11 - it was disk4.  Now that I look closely, I see disk11 is red (red/green colorblindness can be a PITA sometimes!)  I should have fired up unmenu!

 

Not sure what happened to disk11, but it certainly seems to be fine now.  I put the old disk back in disk8, and did the set invalidslot 99 thing, and it is running a parity check now.  37 sync errors early in the disk - to be expected I guess.

 

I checked the syslog I am seeing some issues with disk11.  (smartctl is clean).

 

Nov 27 00:25:14 Tower kernel: ata5.00: exception Emask 0x10 SAct 0x0 SErr 0x1390002 action 0xe frozen
Nov 27 00:25:14 Tower kernel: ata5.00: edma_err 0x00000020
Nov 27 00:25:14 Tower kernel: ata5: SError: { RecovComm PHYRdyChg 10B8B Dispar BadCRC TrStaTrns }
Nov 27 00:25:14 Tower kernel: ata5.00: cmd 25/00:c0:07:22:5d/00:02:02:00:00/e0 tag 0 dma 360448 in
Nov 27 00:25:14 Tower kernel: res 7f/00:c0:07:22:5d/00:02:02:00:00/e0 Emask 0x12 (ATA bus error)
Nov 27 00:25:14 Tower kernel: ata5.00: status: { DRDY DF DRQ ERR }
Nov 27 00:25:14 Tower kernel: ata5: hard resetting link
Nov 27 00:25:19 Tower kernel: ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Nov 27 00:25:19 Tower kernel: ata5.00: configured for UDMA/133
Nov 27 00:25:19 Tower kernel: ata5: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xf t4
Nov 27 00:25:19 Tower kernel: ata5: edma_err 0x000000a8, dev disconnect, EDMA self-disable
Nov 27 00:25:19 Tower kernel: ata5: hard resetting link

 

(This was before the parity check started - there hasn't been another log entry in over 1/2 hour of parity checking.)

 

I think I'll replace the cable and see if that fixes these warnings.

 

Maybe I can actually get around to installing that new disk before bed!

 

Thanks RobJ!

 

Well - I got disk11 to come online and used it to rebuild disk 8.  No errors.

 

Then this morning I tried to spinup the drives and unRAID hung hard.  Had to hit the big red switch.

 

On reboot, disk11 was not recognized.  Replaced some cables and rebooted, and unRAID recognized the drive.  Ran smartctl - no apparent problem.  I then then did the procedure to trust the disk.  It seemed to work and then got a very short way into the parity check and the system quickly took disk11 offline with a flurry or disk errors.  I played with it for about an hour.  Was able to get the disk to be recognized, but attempts to use it took the drive offline.  Smartctl was clean - no remapped sectors or drive reported errors.

 

I replaced the disk and rebuilt onto a new WD drive.  Took most of the day.  All seems to be fine again.  Running a full parity check now.  It found 3 sync errors almost immediately - no more since (it's now about 50G into it).

 

That makes 2 drive failures / rebuilds in 2 days!  Disk 8 was an ancient 500G Maxtor, but the disk11 is a 1 year old 500G Seagate.

the disk11 is a 1 year old 500G Seagate.

That sometimes appends.

I recently had a completly dead drive that was only 6 months old. And I have another that is 8 years old and is running normaly.