TL but please read. 
I know this is a forum primarily for advanced tinkerers in the very latest technology but hear me out.
I’ve been working in the IT field since 1970, have always build my own PCs and retired from that field in 2001.
I have continued to build my own systems since then but 2013 was my last build and one hell of a lot has changed since then.
I have been utilizing raid arrays since my Minicomputer days on HP in the late 1990s.
So I went to mirrored volumes in the mid 2000’s on my PCs and began using AMD based systems.
In 2013 I upgraded to a Gigabyte GA-890FXA-UD5 (rev. 2.0) and built a new system using a raid 5 array with 5 1TB drives. It’s been flawless for 7 years running WIN 7 pro 64.
It’s a strictly old fashioned BIOS based system and that’s what I used to build the array. The AMD support programs for it have been fine but I’ve never had to recover an array …
But support for Win 7 has forced me to move to Win 10 and that’s not possible on that board and some of the later AMD based boards (used) that could utilize my processor, memory and graphic card don’t support the newer technologies and might not make it to the next opsys. So I bit the bullet and found another Gigabyte board that supports enough sata ports and other nice things but it’s an Intel based board. C246-WU4
I realize that I will have to build the array anew and load the data.
So looking this over for a while now I see the first major decision is whether to go legacy Bios or embrace the newer UEFI based methodology?
Gigabyte’s and other documents leave me a bit in the dark about a number of issues as they pertain to Raid arrays.
I keep hearing about people updating their “bios” and suddenly their arrays become broken.
Gigabyte offers 3 ways to build your array.
1. EZ-RAID which I assume operates in a UEFI environment after the OPSY is fully built and loaded. But that’s not completely clear and if so then the upgrading of that UEFI firmware (bios) is possibly an issue no?
2. UFFI Intel Rst this definitely sounds like it’s vulnerable.
3. Legacy Raid via the BIOS which in it’s description gives me the impression that you need to elect not utilizing UEFI mode of for hardware configuration/control and disks would utilize a MBR.
I will be using a separate SSD for the opsys either on some of the remaining sata ports controlled by the Intel chip all designated as RAID type but not utilized in building the raid set. I hope that works. It did on my old AMD board. Or … there’s another AHCI only chip that provides 2 more stata ports so that might become my boot drive.
I will not be booting from the RAID array.
So is the RAID set identical in format for these three methodologies and it’s only the basic environment of whether you are using a MBR that differs?
Is the Legacy RAID operating in an MBR environment immune to the BIOS/UEFI updates causing a failure?
As much as I’d like to move forward I personally find the idea of a corruption of a RAID set because of a BIOS/UEFI update with proper configuring after the update identical to what it was before and before trying to access the disks TOTALLY unacceptable.
So perhaps some of the more knowledgeable folks here can shed some light on this potential issue?
Thanks in advance for any help.
Too much text!
No one will guarantee you that there can’t be problems, and certainly a RAID is no replacement for a backup!
I can’t see the difference between the different configuration tools, information is stored on the disks at least for RSTe RAID 1. MBR-legacy and GPT-UEFI are combinations made up by Microsoft- and partitioning itself has nothing to do with type of underlying RAID. I wouldn’t consider setting up a legacy system in 2020.
I own a C222 motherboard (2014) and update the bios regularily with new RSTe modules, starting with 4.x, now on 6.2 which never was meant for Haswell… Bios update meaning here programming a new blank chip, and the RAID configuration is read from the disks afterwards without any problems.
Well for some reason people are having issues with their raid set when updating the "bios" when the newer UEFI GPT format is being utilized. That makes no sense to me either but there’s something either I or the folks who are having this difficulty don’t understand. So I’m trying get to the how and why this happens. I don’t want to experience that.
So I ran across this article:
https://www.stellarinfo.com/blog/raid-fa…upgrading-bios/
In my experience with Gigabyte MBs utilizing AMD I don’t remember this ever being an issue and I was under the impression, perhaps mistakenly so, that ALL of the RAID array’s information was contained in the array itself and that Bios went out and discovered the array at boot time which is a much longer process with an old fashion BIOS than with the speedier UEFI system. You can watch it scanning the raid drives and then declaring the set size and that it is healthy
Perhaps this the issue here?
If so then that’s a fundamental change for how things work now.
@staatsof :
Welcome to the Win-RAID Forum!
For many years I have used Intel RAID0 arrays as system drive with different Intel chipset systems and I never ran into any problem after a BIOS update or an OS upgrade.
Here are some basic information regarding Intel RAID arrays:
The Intel RAID configuration data are stored by the Intel RAID Utitilty (LEGACY or UEFI doesn’t matter) on a usually hidden track of the RAID array.
Neither an OS update nor a BIOS update can delete or destroy these existing RAID information. A break of an existing RAID array can only occur by a bricked/dead RAID array member or be done by the user himself via Intel RAID Utility). The only thing which may happen is, that the RAID array can not be detected and the RAID information cannot be read by the OS.
This problem may occur
a) after a BIOS update, if the user forgets to set the on-board Intel SATA Controller within the BIOS to “RAID” (note: the DEFAULT setting for modern mainboards is “AHCI”) or
b) after an OS upgrade to a new OS version, if the new in-box Intel RAID driver should not (fully) support the on-board Intel RAID Controller (this will not happen with a modern Intel chipset like yours).
Both problems can easily be solved
a) by recovering the previously used BIOS settings resp.
b) by replacing the Intel RAID driver by a better compatible version.
Questions:
1. Which Intel RAID driver version did you use or do you want to use?
2. Which Intel RAID ROM and EFI RaidDriver version is within the BIOS? You can check it by running the Intel RAID Utility.
Since you obviously are going to build a new Intel RAID array and do a fresh Win10 installation, I recommend to do the following:
1. Install the OS in UEFI mode.
2. Make sure, that the Intel EFI RAID BIOS module version belongs to the same RST development branch as the desired Intel RST RAID driver.
Regards
Dieter (alias Fernando)
@Fernando
When you say same RST development branch. If for exemple I have my EFI RAID BIOS module version 17.5.x.x and I am using drivers 17.5.x.x then I can update with all 17.x.x.x drivers until they release
the version 18.x.x.x right ?
Thanx in advance. Regards.
@Svan :
Yes, you can do that, but if you want to install the latest Intel RST RAID driver v17.8.x.xxxx, you should better update the related Intel RST RAID BIOS module to v17.8.x.xxxx as well.
Thanks Fernando,
In looking over that link I found it wasn’t exactly definitive about what was stored in the “bios” but it did go onto to suggest that simply returning the system to an identical SATA and other IO related configurations should restore the RAID array back to becoming operative. I hope so and that the only thing actually stored is the computers configuration of IO ports. If that’s the cause of all of these people’s difficulties that’s a pretty big Well DUH! Of course you have have the configuration set up the same.
OTOH I have read about the URFI being so much faster to boot because there’s not nearly as much hardware verification do be done upon boot up. I don’t know the details of what that means but having the RAID array defined and stored in a detailed way within the UEFI BIOS sounds like that could speed things up and that’s what concerns me that it’s more than a reset of the configuration! It would have to go to the array and learn the details over again. Which is what I believe my AMD based boards did every time I booted. I wonder if that’s what still happens? I also know none of my AMD boards had trouble if I changed the configuration say to turn off those SATA ports and then turn them back on later. The array was always still there.
I will be loading the latest UEFI “BIOS”, configuring the SATA ports from the Intel chipset to raid and then letting Windows ask for anything that’s missing which I believe won’t be the case but I have the drivers Gigabyte supplied in case I do.
The Intel chipset’s sata ports are 0=>7 Then
Then are two other strictly AHCI sata ports form another ASMedia® ASM1061 chipset.
I want to use two Sata ports for eSata.
Ports 0=>4 are for the array and 5 is for the Bluray drive.
I haven’t made up my if I want to boot off of the AHCI ports with one extra then use ports 6=>7 for the eSata connections on the back panel
Or …
Boot off of port 6 or 7 with one extra there and use the two sata ports from the other chipset for the eStata connectors.
I have to see which actually works???
Complicating all of this a bit is if I want to use any of the much newer and faster methods of connection it says I need to boot from a NVMe SSD connected to one of the M.2 connectors. Perhaps that can come later as THAT has zero to do with the Sata ports and Raid.
Thanks for your help.
EDIT by Fernando: Unneeded fully quoted post removed (to save space)