Jump to content
jbrubaker

Moving drives from non-HBA RAID card to HBA

6 posts in this topic Last Reply

Recommended Posts

First post.  Be kind?

 

I've been running Unraid (currently 6.7.2) for about 4 months now.  My SuperMicro dual Xeon server has developed some issues, possibly related to a power outage or insufficient cooling.  At any rate, I'm putting together a new-from-used-parts machine (Ryzen 7 2700X, X370) and want to move the drives (and the Unraid USB) to the new machine.  Google (and this forum) tell me that Unraid should have no problem identifying the drives and placing them in the correct slot in the array when I first boot the new build.

 

However, I'm a little worried that it will work correctly with my setup.  My SuperMicro is using a 9650SE-12ML RAID card which does not support IT mode.  The drives are setup in "single" mode in the card config, but the controller still sits in front of the disks and prevents "direct" access (e.g. blocks SMART, etc.) and changes the drive identifier string.

 

Here's one of my disks on the RAID controller with the id string: 

Oct 29 20:56:25 Hyperion kernel: md: import disk0: (sdf) 9650SE-12M_DISK_D88RER0842FC52006B26_3600050e042fc52006b26000021e80000 size: 5859363788

 

I am putting an IT-mode RAID card in the new box (Dell H310, LSI 2008) to get SMART support.  I am pretty sure that after I swap the drives to the new system/controller and boot Unraid, the disk identifier for each disk is going to be different on the new controller.

 

Do I simply need to make a note of each drive's actual identifier and then manually match them up with the appropriate slots in Array Devices when I boot the new hardware with the old drives (see attachment)?  Am I making this too complicated?  Am I missing something else important.

 

Thanks for any guidance.

Annotation 2019-10-30 115013.png

Share this post


Link to post

You are correct to be concerned that Unraid will not recognize the disks since their identifier will change.

 

The very most important thing is to not accidentally assign a data disk to the parity slot. As long as you don't do that you should not experience any data loss.

 

If you have enough of the actual serial number to work with, then that should be enough to allow you to reassign the drives correctly. Probably the actual serial number of each disk is printed on each disk label.

 

When you first boot with the flash in the new system, Unraid will not attempt to start since the expected disk identifiers are not the same. You just need to go to Tools - New Config and assign the disks, check the box saying parity is already valid, and start the array. A non-correcting parity check would be a good way to confirm that things are working well.

Share this post


Link to post

There's also a change all disks will be umnountable with an "invalid partition layout" error, if that happens it can be usually be fixed, just don't format the disks.

Share this post


Link to post

Thank you both for your replies.  I attempted the disk move tonight, and as predicted, Unraid said the disks were missing when I booted and "Wrong" when I selected the appropriate disk.

 

I created a new config as recommended by @trurl, checked "Parity already valid", and started the array, then got the "Unmountable: Unsupported partition layout" on each of the disks (except parity) that had been connected to the previous RAID controller (now on the Dell H310).

 

When the system was booting, I believe I saw something flash by about the GPT layout sector something not being at the end of disk or something.

 

I did some Googling and couldn't find many useful hints at what to try.

 

Any thoughts?

 

Screen Shot 2019-12-01 at 11.55.05 PM.png

Screen Shot 2019-12-01 at 11.55.11 PM.png

 

Edit:  Found this in the log:

"Alternate GPT header not at the end of the disk"

Dec  1 23:42:30 Hyperion kernel: ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec  1 23:42:30 Hyperion kernel: ata4.00: ATA-9: ST3000DM001-1ER166,             Z501REW5, CC25, max UDMA/133
Dec  1 23:42:30 Hyperion kernel: ata4.00: 5860533168 sectors, multi 16: LBA48 NCQ (depth 32), AA
Dec  1 23:42:30 Hyperion kernel: ata4.00: configured for UDMA/133
Dec  1 23:42:30 Hyperion kernel: scsi 4:0:0:0: Direct-Access     ATA      ST3000DM001-1ER1 CC25 PQ: 0 ANSI: 5
Dec  1 23:42:30 Hyperion kernel: sd 4:0:0:0: Attached scsi generic sg3 type 0
Dec  1 23:42:30 Hyperion kernel: sd 4:0:0:0: [sdd] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
Dec  1 23:42:30 Hyperion kernel: sd 4:0:0:0: [sdd] 4096-byte physical blocks
Dec  1 23:42:30 Hyperion kernel: sd 4:0:0:0: [sdd] Write Protect is off
Dec  1 23:42:30 Hyperion kernel: sd 4:0:0:0: [sdd] Mode Sense: 00 3a 00 00
Dec  1 23:42:30 Hyperion kernel: sd 4:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Dec  1 23:42:30 Hyperion kernel: mpt2sas_cm0: host_add: handle(0x0001), sas_addr(0x5000000080000000), phys(8)
Dec  1 23:42:30 Hyperion kernel: GPT:Primary header thinks Alt. header is not at the end of the disk.
Dec  1 23:42:30 Hyperion kernel: GPT:5859352575 != 5860533167
Dec  1 23:42:30 Hyperion kernel: GPT:Alternate GPT header not at the end of the disk.
Dec  1 23:42:30 Hyperion kernel: GPT:5859352575 != 5860533167
Dec  1 23:42:30 Hyperion kernel: GPT: Use GNU Parted to correct GPT errors.
Dec  1 23:42:30 Hyperion kernel: sdd: sdd1

 

Edited by jbrubaker

Share this post


Link to post

Like mentioned it was a possibility, since partitions are outside parity this can usually be fixed by rebuilding one disk at a time so Unraid recreates the partitions correctly, you can check by unassigning one of the data disks, start the array and check if the emulated disk mounts and data looks correct, if yes you can rebuild on top, then repeat for all other disks one by one.

Share this post


Link to post
8 hours ago, johnnie.black said:

Like mentioned it was a possibility, since partitions are outside parity this can usually be fixed by rebuilding one disk at a time so Unraid recreates the partitions correctly, you can check by unassigning one of the data disks, start the array and check if the emulated disk mounts and data looks correct, if yes you can rebuild on top, then repeat for all other disks one by one.

Thanks for your help.

 

I stopped array, and mounted one of the array disks in Unassigned Devices.  All the data I checked was intact.  I unmounted it from Unassigned Devices, and with it unassigned from the array, I started the array.

 

The emulated disk mounted and as far as I can tell the data still looks good, so I think I can proceed to rebuilding the disk.  Running the first disk rebuild now.

Share this post


Link to post

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.