What you wrote is on the right track, and it matches what
ws1960 described about the Supermicro X8ST3‑F + LSI RAID + Server 2019 setup (OS won’t boot without the LSI card, MegaRAID screen freezing, rebuild stopped mid-way). st “next actions” checklist*
to move this forward without* accidentally wiping RAID metadata.
0) Two “do not do” rules (until data is safe)
1)
Do NOT click “Initialize” (or any option that suggests clearing/initializing drives/foreign config) unless you are 100% sure the data is disposable.
2)
Do NOT keep power-cycling repeatedly while the controller is doing rebuild/consistency operations (it can worsen corruption).
Those warnings are especially important given the freeze + interrupted rebuild scenario.
1) Yes — than be a real variable (remove it)
On older boards/firmware, wireless all‑in‑one keyboards can behave badly in:
- BIOS
- MegaRAID pre-boot utilities
Best test: use a
basic wired USB keyboard plugged directly into a
rear USB port (no hub). This is a cheap, easy variable to eliminate before assuming the RAID card is dying.
2) Yes — the OS “disappears” witpected)
If Windows Server is installed on SSDs that are members of an LSI virtual disk (RAID1, RAID10, etc.), then removing the controller makes that virtual disk vanish, so the system won’t boot even though the physical SSDs are still present.
3) Treat “MegaRAID utility freezes” as a **hardware-proven otherwise
When the
pre-boot RAID utility locks up, the cause is often one of these:
- A second drive in the array is struggling (timeouts during scan/rebuild)
- Bad SAS/SATA cable / backplane slot causing link resets
- The RAID controller itself (overheating, failing cache/BBU module, failing card)
- Firmware oddities on older platforms
Because it’s pre-OS, Windows itself is usually
not the root cause of the freeze.
4) Safest immediate troubleshooting steps (in order)
Step A — Observe t
In the MegaRAID BIOS/WebBIOS:
- Look for array state: Optimal / Degraded / Offline
- Look for any drive flagged: Failed / Unconfigured(bad) / Predictive failure
- If you can access it, check the event log
If it freezes immediately when you “Start,” try leaving it alone for 5–10 minutes once (some controllers appear frozen while enumerating/problem-solving a slow device).
Step B — Check physical layer (high value, low risk)
Power down and:
- Reseat the LSI card
- Reseat/replace the SAS/SATA cable(s) from controller to backplane/drives
- If there’s a backplane: move the “suspect” drive to a different bay (note which bay was which)
- Ensure the card has airflow (older LSI cards can misbehave when hot)
Step C — Stop guessing: identify exact hardware + layout
Ask ws1960 for:
- Exact LSI card model (e.g., 9260‑8i / 9271 / etc.)
- Which arrays exist (example: “OS RAID1 on SSDs” + “Data RAID6 on HDDs”)
- Whether the rebuild that stopped was the OS array or the data array
- Whether the data is critical (must preserve) vs “rebuild is OK”
5) Best next “information to request” from ws1960
To avoid wrong moves, the most helpful details would be:
1)
LSI card model + firmware version (photo of the BIOS header screen is fine)
2)
How many drives in each array (and their sizes/models)
3)
Which physical drive was replaced (slot/bay number)
4) What the controller says now:
Degraded? Rebuild stopped at what %?
5) Whether Supermicro
IPMI is available on that board (it often is on X8 server boards). If yes, In sometimes avoid weird USB keyboard issues in preboot.
If the data is critical
If this is important/irreplaceable data and the controller/utility keeps freezing, the safest posture is:
- Stop “repair attempts”
- Gather info (photos, logs if possible)
- Consider a known-good identical controller swap only after confirming the correct procedure (LSI cards can be picky about foreign config/import steps)
If you want, paste ws1960’s answers (LSI model, whether OS SSDs are on the LSI, and whether the data is critical). Then I’ll lay out a
very specific, lowest-risk plan for either (A) recovery-first or (B) clean rebuild.
