SAS-Festplatten nach Entfernen von RAID (IT-Mode) werden im OS nicht erkannt – Hilfe gesucht

[hpoperator]

Hallo zusammen,

ich stehe aktuell vor folgendem Problem: Ich habe einen Server mit zahlreichen SAS-Festplatten, auf denen ursprünglich ein Hardware-RAID lief. Ziel war es, die Platten einzeln nutzbar zu machen, das scheint auch fast gelungen, aber im Betriebssystem bleiben die Laufwerke unsichtbar.

System & Setup:

• Server mit 24 × 3,5″ SAS-Festplatten (zu a 10 TB) und 7x 2,5" SSD-Platten (zu a 1TB)
• Mainboard: Supermicro X10SRL-F
• Speicher: 128 GB RDIMM DDR4 (8x 16GB Riegel)
• CPU: Xeon E5-2697A v4
• Erweiterung: 4 × LSI SAS9211-8i (SAS-HBA), dazu 2 × Mellanox ConnectX-4 Netzwerkkarten mit 4x Finisar FTLX1471D3BCL Modulen

Bisherige Schritte:

1. BIOS auf UEFI umgestellt und Secure Boot deaktiviert.
2. Alle 4 LSI-Karten erfolgreich mit IT-Mode-Firmware geflasht. Firmware-Check mit

   sas2flash.efi -listall

3. Im LSI-BIOS (via Ctrl+C) werden alle Festplatten unter „SAS Topology“, die zu der jeweiligen LSI-Karte gehören, korrekt angezeigt.
4. Von einem Live-Medium (GParted Live und Hiren’s Boot CD / WinPE) gebootet: Nur die SSDs tauchen auf, SAS-Festplatten bleiben unsichtbar oder erscheinen unter diskpart mit „Größe: 0 Byte“.
5. Verschiedene Tools wie CrystalDiskInfo, HWInfo, wurden ebenfalls schon genutzt. Bei einigen werden die SAS-Platten gelistet jedoch dort nur eingeschränkt.
6. Verkabelung (jede Platte einzeln) prinzipiell korrekt, keine Fehler ersichtlich.

Fragestellungen:

• Was kann ich jetzt tun, damit die SAS-Platten sichtbar und nutzbar werden?
• Muss ich nach dem Flash ins IT-Mode noch spezielle Schritte ausführen (z. B. BIOS-Einstellungen, Treiber)
• Gibt es Tools oder Methoden, um eventuell noch vorhandene RAID-Metadaten zu entfernen, obwohl die Platten nicht angezeigt werden?
• Oder liegt das Problem tiefer (z. B. Firmware, Board-Kompatibilität, Host-Adapter-Einstellungen)?

Ich freue mich über konkrete Tipps, die mich weiterbringen, ob per Linux-Tool, DOS/WinPE, BIOS-Check oder anders.

Vielen Dank schon mal für eure Unterstützung!

 

[kaiser]

mhmm Windows. Würde sagen, dass der passende Treiber für die SAS Controller nicht installiert ist.

 

[Holt]

Kanne es sein, dass die Platten im RAID mit einer anderen Sektorgröße formatiert wurden? Bei SAS HW RAIDs ist es nicht ungewöhnlich, dass man dort Sektorgrößen von 520 oder 528 Bytes verwendet und der Controller dann in die übrigen 8 bzw. 16 Byte eine eigene ECC schreibt und sich die Rohdaten von den Platten liefern lässt. Dann kann er selbst prüfen ob die gelesenen Daten korrekt sind und wenn nicht, sie sofort mit Hilfe der Redundanz des RAIDs rekonstruieren. Dies geht bei SATA nicht, daher gibt es dort die TLER, also die Option den Timeout einzustellen, wie lange eine HDD versuchen soll einen problematischen Sektor doch noch erfolgreich zu lesen, denn hinter jedem Sektor steht ja immer auch eine ECC und der Controller der Platte prüft damit ob de Daten korrekt gelesen wurden und versucht sie zu korrigieren. Klappt das nicht, versucht er durch wiederholtes Lesen mit anderen Parametern die Daten doch nicht erfolgreich zu lesen und gibt erst nach einem Timeout auf und liefert einen Lesefehler (und markiert den Sektor als schwebend), wenn es ihm nicht gelingt.

Dies Timeout beträgt bei normalen Desktop Platten normalerweise 14s, bei NAS Platten üblicherweise 7s und ist aber bei denen einstellbar, was WD eben als TLER bezeichnet. Trotzdem führt es aber zu einer deutlichen Verzögerung, wenn es mal nicht gelingt die Daten eines Sektors sofort korrekt zu lesen und um dies zu vermeiden, werden eben bei SAS Hardware RAIDs die Sektoren auf eine größere Kapazität formatiert und der Controller übernimmt die Fehlererkennung selbst. Wobei ich wirklich die Sektorgröße der Platten meine, nicht die Clustergröße des Filesystems! Allerdings kommen die Betriebssysteme nicht mit Platten klar, bei denen die Sektorgröße nicht 512 oder 4096 Byte beträgt und daher muss man solche Platten dann erst wieder auf 512 Byte formatieren um sie als Einzellaufwerke nutzen zu können.

 

[hpoperator]

Guten Morgen,

vielen Dank für eure Antworten!
Das mit der Sektorgröße ist ein sehr guter Punkt, der mir so nicht bekannt war.
Wie aber kann ich die SAS-Platten auf die entsprechenden Bytes formatieren, wenn ich sie, beispielsweiße über gparted-Live, nicht sehen und anwählen kann?

@kaiser
ok, das mit Windows verstehe ich und könnte definitv möglich sein, aber gparted-live (linux) zeigt die Platten ja auch nicht an 🤷‍♂️

 

[Holt]

Wie aber kann ich die SAS-Platten auf die entsprechenden Bytes formatieren, wenn ich sie, beispielsweiße über gparted-Live, nicht sehen und anwählen kann?

Da fehlt vermutlich der passende Treiber, denn musst Du hier suchen und herunterladen:

Support Documents and Downloads

Search technical documentation and downloads including firmware and drivers.

www.broadcom.com

Wobei die Treiber alle für alte Windows und Linux Versionen sind, die Dinger sind ja auch schon recht alt. Deswegen sind sie billig zu haben, aber es hat eben auch einen Grund, warum die fast nichts kosten.

 

[hpoperator]

@Holt
ok, danke dir!
Laut dem "HBA User Guide" ist die Karte mit Linux kompatibel, da mpt3sas ein Kernel-Modul ist, welches die Karten unterstützt.
Statt den "Gparted-Live-Stick" führe ich mal SystemRescue oder Ubuntu Live-USB aus und schaue, ob dies mpt3sas mitbringt (lsmod | grep mpt3sas) und ich die Platten somit ansprechen kann.
Sollte dies nicht zielführend sein, installiere ich die Treiber manuell nach.

 

[underclocker2k4]

Zum Spaß mal Windows 10 installieren?! (geht auch ohne Key)
Das dürfte bei der Kompatibilität kein Thema sein.

Wobei ich aber sagen muss, dass ich mit nem Ubuntu oder CentOS keine Schmerzen mit SAS2 LSI Controllern hatte.
Das lief eigentlich out of the Box.

 

[hpoperator]

Bin jetzt mit meinem "Latein" am Ende.....
ich habe jetzt diese zwei Netzwerkkarten ausgebaut und auch alle 9211-81.
Ich steckte EINE 9211-8i in den PCIe-Slot und startete den Server. Es kam kein LSI-Bootscreen, also die Stelle, an der ich strg+c drücken könnte um ins "LSI-BIOS" zu gelangen. Auch im Nachgang, unter dem gpartet-live wurde sie nicht erkannt. Auch nicht unter der Distri Ubuntu, welche ich installieren wollte. Angezeigt wurde mir nur das USB-Medium auf dem sich gparted-live befindet.
Also steckte ich diese 9211-8i aus und versuchte es mit der nächsten (an einem anden PCIe-Slot), selbiges Ergebnis. und dann teste ich die nächste, bis ich bei der vierten Karte angekommen bin. Bei keiner Karte wurde der LSI-Bootscreen angezeigt und keine Karte wurde erkannt.

nun das Seltsame......

Stecke ich wieder ALLE VIER 9211-8i in die PCIe-Slots und starte den Server, wird mir der LSI-Bootscreen angezeigt.

Ich ging dann ins LSI-BIOS und sah, dass dort alle vier Karten korrekt aufgeführt werden. Auch werden mir die an die jeweilige Karte angeschlossenen SAS-Platten korrekt aufgelistet.
Ich sah zwar auch, dass sich die Bootreihenfolge im LSI-BIOS geändert hatte (wahrscheinlich weil ich die Platten ausgesteckt hatte), also hinterlegte ich diese wieder und startete neu.
Was mir aufgefallen ist: Wenn der gparted bootet, bekomme ich zu den Platten fehlermeldungen aufgelistet (siehe screenshot): "Asking for cache data failed"

Natürlich bekomme ich in gparted noch immer nur die SSDs angezeigt und nicht die SAS-Platten.

 

[hpoperator]

ich nahm gestern abend meinen Fujitsu Esprimo D556/E85+ hervor (ist nur HAASos / HomeAssistant installiert), steckte eine 9211-8i-Karte, sammt angeschlossener SAS-Platten (Stromversorgung läuft allerdings weiterhin über den Server, weil das Netzteil des Eprimos zu schwachbrüstig ist) in den PCIe-Slot und startete den Rechner. Leider komme ich hier nicht in das LSI-BIOS, keine Ahnung warum, aber ich bekomme das diesbezügliche Boot-Fenster mit der Info zu dem Befehl strg+C nicht angezeigt.

Habe nun mit HBCD gestartet und, ebenfalls keine Ahnung warum, bekomme ich unter Utilities --> Hard Disk Tools --> kein GSmart mehr angezeigt, auch fehlen andere Programme, die beim erststart, als ich beim Beitrag die Screenshots hochgeladen habe, noch da waren. Habe die selbe ISO genutzt, den gleichen USB-Stick, unterschiedliche USB-Ports an dem Esprimo. Irgendwie läuft alles schief :utminigun:

Nunja, versuchte das beste aus der Situation zu machen warf die Eingabeaufforderung an und listete mit diskapart alle festplatten auf. Auch schaute ich mir die details der Festplatten an (habe nur von dreien ein screenshot erstellt, da die informationen bei allen anderen HUH gleich war). Danch führte ich den Befehl "clean" aus = komischerweise erfolgreich. Nur Formatieren möchte er mir die nicht

 

[hpoperator]

Kanne es sein, dass die Platten im RAID mit einer anderen Sektorgröße formatiert wurden? Bei SAS HW RAIDs ist es nicht ungewöhnlich, dass man dort Sektorgrößen von 520 oder 528 Bytes verwendet und der Controller dann in die übrigen 8 bzw. 16 Byte eine eigene ECC schreibt und sich die Rohdaten von den Platten liefern lässt. Dann kann er selbst prüfen ob die gelesenen Daten korrekt sind und wenn nicht, sie sofort mit Hilfe der Redundanz des RAIDs rekonstruieren. Dies geht bei SATA nicht, daher gibt es dort die TLER, also die Option den Timeout einzustellen, wie lange eine HDD versuchen soll einen problematischen Sektor doch noch erfolgreich zu lesen, denn hinter jedem Sektor steht ja immer auch eine ECC und der Controller der Platte prüft damit ob de Daten korrekt gelesen wurden und versucht sie zu korrigieren. Klappt das nicht, versucht er durch wiederholtes Lesen mit anderen Parametern die Daten doch nicht erfolgreich zu lesen und gibt erst nach einem Timeout auf und liefert einen Lesefehler (und markiert den Sektor als schwebend), wenn es ihm nicht gelingt.

Dies Timeout beträgt bei normalen Desktop Platten normalerweise 14s, bei NAS Platten üblicherweise 7s und ist aber bei denen einstellbar, was WD eben als TLER bezeichnet. Trotzdem führt es aber zu einer deutlichen Verzögerung, wenn es mal nicht gelingt die Daten eines Sektors sofort korrekt zu lesen und um dies zu vermeiden, werden eben bei SAS Hardware RAIDs die Sektoren auf eine größere Kapazität formatiert und der Controller übernimmt die Fehlererkennung selbst. Wobei ich wirklich die Sektorgröße der Platten meine, nicht die Clustergröße des Filesystems! Allerdings kommen die Betriebssysteme nicht mit Platten klar, bei denen die Sektorgröße nicht 512 oder 4096 Byte beträgt und daher muss man solche Platten dann erst wieder auf 512 Byte formatieren um sie als Einzellaufwerke nutzen zu können.

genau das ist nach allem was ich sehe, der wahrscheinlichtse fall.
Wie kann ich denn die Platten in Ihren Ursprungs-Sektorgröße zurücksetzen, denn diese wird leider in diesem Zustand nicht erkannt und kann mit den mir bekannten Mitteln, nicht formatieren.

 

[Holt]

Dies müsste mit sg_format gehen, laut Googles AI mit sg_format--format --size=512 --fmtpinfo=0 /dev/sgX, wobei das /dev/sgX natürlich durch das Device der jeweiligen Platte zu ersetzen ist. Das --size=512 wäre für HDD die jetzt mit 520 oder 528 Bytes pro Sektor formatiert sind, dies gibt es aber analog auf für 4kn Platten. sg_scan -i oder smartctl -a /dev/sgX sollten eigentlich die aktuelle Sektorgröße anzeigen.

 

[hpoperator]

ok, danke vielmals! @Holt
wo erkenne ich denn die sektorgröße?

 

[Holt]

Gute Frage, was gibt smartctl -a aus? Da kann man es oben recht einfach erkennen. Hier z.B: für meine NVME SSD: "Namespace 1 Formatted LBA Size: 512" und für eine SATA SSD: "Sector Size: 512 bytes logical/physical"

 

[hpoperator]

@Holt

smartctl -a /dev/sg1

siehe screenshot....

sämtliche Befehle, wie sg_readcap ; sg_vpd
sind nicht zielführend, entweder ich bekomme die Meldung: Device not ready, oder sonstige Fehlermeldungen.
Die Information über die Sektorgröße rückt er nicht heraus

Gefühlt hätte ich darauf getippt, dass die 9211-8i noch immer im IR-Mode ist, doch im LSI-BIOS wird ganz klar der IT-Mode deklariert (siehe screenshot in den letzten Antworten)

 

[hpoperator]

ich habe nun jetzt mal ein bischen mit dem ubuntu-live-system herumgespielt. Bin dort in die Eingabeaufforderung und versuchte mit OpenSeaChest-Basic weiter zu kommen, leider ohne Ergebnis:
hier die Ausgabe von sudo ./openSeaChest_Basics -d /dev/sg1 -i

========================================================================================== openSeaChest_Basics - openSeaChest drive utilities - NVMe Enabled Copyright (c) 2014-2025 Seagate Technology LLC and/or its Affiliates, All Rights Reserved openSeaChest_Basics Version: 3.7.2 X86_64 Build Date: Sep 1 2025 Today: 20250901T190757 User: root ========================================================================================== Attempting to open handle "/dev/sg1" get_Lin_Device: Getting device for /dev/sg1 get_Lin_Device: Attempting to open /dev/sg1 Getting SG SCSI address Getting SG driver version Setting interface, drive type, secondary handles SCSI interface! Partition count for /dev/sdb = 0 name = /dev/sg1 friendly name = sg1 2ndName = /dev/sdb 2ndFName = sdb h:c:t:l = 1:0:1:0 SG driver version = 3.5.36 fill_Drive_Info_Data: -->
fill_In_Device_Info: --> -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0)
-->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io
<--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO
-->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io
<--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) fill_In_ATA_Drive_Info --> -->send_IO -->send_sg_io
<--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0)
Drive type: 2
Interface type: 2
Media type: 0
SN: 7PGA92YG
fill_In_ATA_Drive_Info <-- scsi helper
Drive type: 2 Interface type: 2
Media type: 0 fill_In_Device_Info: <-- Drive type: 2 Interface type: 2 Media type: 0 fill_Drive_Info_Data:
<-- sg helper Drive type: 2 Interface type: 2 Media type: 0 /dev/sg1 - HUH721010AL4200 -
7PGA92YG - A923 - SCSI -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0)
-->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io
<--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO
-->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io
<--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0)
-->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io
<--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO
-->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO
-->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO
-->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO
-->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO
-->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO
-->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO
-->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO
-->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO
-->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO
-->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0)
<--send_IO (0) -->send_IO -->send_sg_io <--send_sg_io (0) <--send_IO (0) -->send_IO
-->send_sg_io <--send_sg_io (0) <--send_IO (0)
Vendor ID: HGST
Model Number: HUH721010AL4200
Serial Number: 7PGA92YG
Firmware Revision: A923
World Wide Name: 5000CCA25112B768 Drive Capacity (B/B): 0.00/0.00
Temperature Data: Current Temperature (C): 57
Highest Temperature (C): Not Reported
Lowest Temperature (C): Not Reported
Power On Time: Not Reported
Power On Hours: Not Reported
MaxLBA: 0
Native MaxLBA: Not Reported
Logical Sector Size (B): 0
Physical Sector Size (B): 0
Sector Alignment: 0
Rotation Rate (RPM): 7200
Form Factor: 3.5"
Last DST information: Not supported
Long Drive Self Test Time: 19 hours 28 minutes
Interface speed: Not Reported
Annualized Workload Rate (TB/yr): Not Reported
Total Bytes Read (B): Not Reported
Total Bytes Written (B): Not Reported
Encryption Support: Not Supported
Cache Size (MiB): Not Reported
Read Look-Ahead: Not Supported
Write Cache: Not Supported
SMART Status: Good
ATA Security Information: Not Supported
Firmware Download Support: Not Supported
Number of Logical Units: 1
Specifications Supported: SPC-4
Features Supported: Power Consumption Protection Type 1 Protection Type 2
Adapter Information: Adapter Type: PCI Vendor ID: 1000h Product ID: 0072h Revision: 0003h

chatGPT spuckt folgendes aus:

Deine HGST-HDD zeigt 0 für Logical Sector Size, Physical Sector Size und MaxLBA. Das heißt:

• Die Platte ist SCSI/SAS-Hardware-Raid-geschützt oder in einem „IT-Mode/RAID-Mode“ des Controllers.
• Linux kann sie nicht als normale HDD ansprechen, auch SeaChest erkennt sie zwar als Gerät, kann aber keine Sektoren auslesen oder formatieren.

---

Konsequenzen​

1. Keine Sektorgröße → Du kannst sie nicht mit 512 oder 520 formatieren.
2. MaxLBA = 0 → Das Laufwerk meldet sich quasi nicht nutzbar, wie ein „geblocktes“ Device.
3. Ursache: Die Platte war wahrscheinlich im RAID-Modus des Controllers, und der Controller hat die Platte reserviert/initialisiert.

---

Mögliche Lösungen​

1. RAID-Mode deaktivieren / IT-Mode aktivieren
   • Wenn die Platte in einem HP-RAID-Controller steckt:
     • Controller in HBA/IT-Mode umstellen
     • Platte aus RAID-Verbund entfernen
     • Dann MaxLBA/Logical Sector sichtbar → SeaChest kann formatieren
2. Controller wechseln
   • Wenn IT-Mode nicht möglich, Platte in einen reinen SAS-HBA-Controller stecken
   • Dann mit SeaChest formatieren
3. Firmware/Low-Level-Reset
   • Manche HGST SAS-Laufwerke benötigen Seagate SeaChest „Low-Level Format“ oder „Security Initialize“, aber nur auf einem freien HBA, sonst MaxLBA=0

---

💡 Kurz gesagt: Du kannst diese Platte aktuell nicht direkt in SystemRescue formatieren, weil der Controller/Mode sie blockiert. Es liegt nicht an SeaChest oder Linux, sondern an Controller/Firmware-Level.

kann dies jemand bestätigen?
Wäre es vielleicht zielführend erneut in den IT-Mode zu flashen? Obwohl mir im LSI-BIOS der IT-Mode angezeigt wird?

 

[MentalVerschreckt]

Hast du keine Möglichkeit auf Controllerebene die HDs zu ereasen oder zu initialisieren?