I thought I was replacing a data drive correctly, per the documentation, and it automatically started and completed the rebuild. Unfortunately, the drive now won't mount and says it is an unsupported partition format. It has a green ball beside the drive.  Should I have formatted the drive prior to swapping it in for the old one? 

 

Now, I can't swap the old drive back in because it's too small. What should I do to get this back under control? 

 

Unraid v6.8.0, in case it matters. 

 

Thanks

Edited December 29, 20196 yr by herg

Go to Tools | Diagnostics and download the diagnostics then post that in a reply. Also, indicate which drive you're attempting to add, just to help zero in on the right place for the experts to look.

Thanks. The diagnostics file is attached. sdi (disk2) is the newly added drive. sdh is what it replaced. 

turanga-diagnostics-20191228-1308.zip

I stopped the array and mounted the new drive from the command line.  It still has the old directory listing, so it seems like it did not restore data to the new drive. It did, however, run for about 8 hours doing a rebuild.  Is there a way to determine if it treated the new drive as good data and updated the parity drive instead of using parity to restore the data drive?

 

I really don't know the best way to handle this, which is why I'm asking, but it feels like I'll have to format the new drive, rebuild parity, then copy files from the old drive back onto the array. Any better suggestions?  Ideas as to what went wrong? 

 

 

6 minutes ago, herg said:

Any better suggestions?

DO NOT FORMAT YOUR DRIVE! THAT WILL NOT RECOVER ANY DATA!

 

Hold on, twiddle your thumbs, go take a walk, kill some aliens, something, but step away from the server!!!

 

I'm not the expert, but one will be along who can give you some advice on how to recover.

Understood.  FWIW, the data is still available on the old drive, so it doesn't necessarily have to be rebuilt from parity. 

 

I'm migrating to Unraid from Flexraid, so I'm used to handling things myself. I'm going to blame my impatience on that.

Usually response is pretty quick 'round these parts, but with the holidays, I'm guessing people are on vacation and not responding as normal. There are still a few stalwarts hanging out here, so just keep twiddling your thumbs, they'll stop by. 

 

(took about 7-8 hours to get a response to my question today, just to give you an idea)

 

Rereading your OP, if you were doing a rebuild of a drive onto a larger drive, there's no formatting necessary. As I understand it, the OS will rebuild the disk bit-by-bit from parity and the other drives. Also, I'm not sure why you couldn't put the original drive back in, even if the new drive is larger, the old one should slot right in. I'm trying to think through the 3-disk-parity-upgrade-data-swap procedure and even that shouldn't be an issue. I don't think. Maybe more details for whoever manages to stop by would help out.

No worries.  I can understand the holidays affecting things. 

 

I'm not sure what else to mention. The new drive was already formatted xfs for use in a Flexraid array.  I had moved files from the unassigned drive to others already in the array. After it was empty, I was trying to replace one of the small drives in the array with the newly emptied drive. I stopped the array, then changed the disk2 dropdown to the new drive and restarted it. It seemed to rebuild disk2 on the new drive, but now looking at the log, it appears there was an automatic partitioning step that failed. The old (empty) directories are still on the new disk2.

 

When I look at the partition table on the new drive, it is slightly different than a drive formatted by Unraid.  The new drive says it's still using a GPT, and the partition starts at sector 64.  The Unraid drive is MBR and sector 63.

Rebooting should fix it, it needs to refresh the partition table, if it doesn't post new diags.

Sure enough, the reboot seems to have completely fixed it, including the fact that the rebuilt data is on the drive.  I considered rebooting, but I had convinced myself that couldn't be it.  Embarrassed, but happy.  Thanks.

It's usually not needed for a rebuild, but sometimes for some reason partition info needs to be refreshed, and easiest way to do that is a reboot.

 

Dec 27 23:36:48 turanga emhttpd: shcmd (1561): sgdisk -o -a 8 -n 1:32K:0 /dev/sdi
Dec 27 23:36:49 turanga root: Creating new GPT entries in memory.
Dec 27 23:36:49 turanga root: Warning: The kernel is still using the old partition table.
Dec 27 23:36:49 turanga root: The new table will be used at the next reboot or after you
Dec 27 23:36:49 turanga root: run partprobe(8) or kpartx(8)