jonathanm

What do you mean by that last statement? Parity2 calculates from the array disks, not Parity1.

Do the power supplies that you are using have modular cables? If so, did you keep the cables with the supplies that they came with, or did you just swap the supplies and leave the cables in place? Many times they are pinned differently at the power supply end of the cable.

First guess would be power supply plug upside down.

Not at the moment. But you can use ControlR to do what you want.

If your motherboard supports booting without video, some do, some don't, there may be a setting to halt on errors (no GPU detected) or not.

Given the totality of the situation, I think the best method is the path of least resistance, that being using the network to transfer the data using windows native tools. In your situation, assuming the ONLY data we are talking about is the existing windows stuff, that is, nothing currently on the array, I would, in this order, 1. Temporarily unassign the parity drive(s). This enables the highest write speed possible, and since the data is still on the windows box, the risk of a drive loss losing data is extremely low. 2. Checksum the entire drive contents in windows. Several different tools available to do that. 3. Set up shares on unraid to reflect what you need. 4. Copy (not move) data across the network to unraid. I wouldn't bother with third party apps, just use built in windows copy. 5. Checksum the data on unraid. Compare checksums to ensure an accurate copy. 6. Move windows drives into unraid array. DO NOT FORMAT THEM, just assign them as data drives, and reassign the parity drive(s) to build parity. 7. Once parity is built successfully and checked, then you can format the old windows drives. Until they are formatted, they will retain the NTFS data but won't be readable in the array. If something goes wrong they can be recovered using testdisk. This procedure is admittedly slow, but very safe. How much time is safety worth to you? Do you have backups of this data elsewhere? unraid is not a substitute for backups, and it seems you have plenty of space. Maybe it would be better to leave the windows drives intact and store them for backup.

@surfshack66, what warning message would have been sufficient for you to stop and reconsider? Would changing the second line to "This is not used to rebuild a failed drive" help at all?

Maybe your postman has it out for you.

Were they all purchased at the same time? Maybe somebody dropped the pallet.

Looks like bad video RAM to me, which if you have an embedded GPU means system RAM. Try running the memtest from the unraid USB boot screen.

I think there may have been a misunderstanding, my fault. I was asking if you were going to be active in the unraid forums, supporting your app. Not if this thread was for support. Since I have seen a few posts by you in the support thread, the answer is YES, the author of the app will be providing support on the unraid forum site. That is not always the case, and since you posted here advertising your app, I wanted a clear answer if you would be active on the unraid site, dealing with unraid specific issues that come up with your app.

The ethernet is fine, I've been using it as a pfsense router with a PCI 10/100 card for the second interface for years now. It's the VIA C7 with no AES-NI support that is the issue.

Sounds like a NO for support directly from you on this forum. Why did you post here?

Since flash is exported regardless of whether the array is started, it does need to be handled differently. The share settings page isn't available until the array is started.

All your shares should be online and available now. However, you should avoid a whole lot of file activity, as it will slow down the parity build. If you had users and user security set up, all that will be gone and need to be reset.