RAID to passthrough: the Dell T140 conversion

Most decommissioned servers arrive with a hardware RAID controller between the drives and the operating system. That controller is the single biggest reason erasure software reports "no drives found". This is the field note from one bench conversion, a Dell PowerEdge T140 whose PERC H330 went from hiding every SAS drive to passing them through, one by one, for firmware-level sanitise — with the exact firmware, the exact flash sequence, and the exact boot output at the end.

Why a RAID card gets in the way of erasure

A hardware RAID controller exposes virtual disks, not physical drives. Erasure is a per-drive act: the drive must be addressed directly for ATA Secure Erase or SCSI SANITIZE, and its identity and health must be read from the device itself — the serial number lives in SCSI VPD page 0x80, the health in SCSI LOG SENSE, and the sanitise completion status in the drive's own sense data. Behind a virtual disk none of that exists, because the controller answers those queries on behalf of an array, not of a drive.

It is not just a visibility problem. Erasure evidence means per-drive facts: which serial was wiped, by what opcode, with what completion status. A tool that can only see "Virtual Disk 0" cannot produce that. The PERC H330 is a good example of the worst case: it is an LSI SAS3008 chip running RAID-only firmware, and its controller profile reports "Secure JBOD support: No" — there is no supported way to present raw drives at all.

The controller, precisely

The H330 and Dell's HBA330 share the same silicon: a Broadcom (LSI) SAS3008 "Fury" Fusion-MPT controller. The difference is entirely in the firmware image on the card's flash and the PCI identity it presents:

• PERC H330 — RAID (IR) firmware, PCI ID 1000:005f, driven by the megaraid_sas stack. Disks appear as members of arrays, or not at all.
• HBA330 — IT firmware, PCI ID 1000:0097, driven by mpt3sas. Every phy and drive is handed straight to the OS.

The conversion swaps one firmware personality for the other. The HBA firmware flashed here is Dell's own image — HBA330.fw from the official SAS_HBA330_ADP_SF.fw v16.17.01.00 A08 update package, SHA-256 2be9c8b2…3a58 verified against Dell's published checksum — with Dell's mptx64-sas3-sb.rom as the card BIOS. Nothing flashed on this card came from a random zip.

What we found on the T140

This particular card had a second problem. Its RAID firmware had stopped answering the driver's commands — megaraid_sas DCMD timeouts and a boot log ending in Failed from megasas_init_fw 6553 — so the host never completed controller initialisation and no drives appeared, even as array members. The machine's own setup screens offered a foreign configuration that could not be imported, and clearing it did not help. A card that cannot finish initialisation is a locked door in front of the drives: nothing in software can reach around it.

The fix was to stop treating the card as a RAID controller altogether — and since the flash is a field operation, the first rule is that a card already misbehaving gets its stock firmware updated (or the card swapped) before anything riskier is attempted. Flashing a hung card bricks it.

The conversion

The toolchain is the LSI DOS set — megacli.exe (identity and inventory), megarec3.exe (flash erase), sas3flsh.exe (flash and SAS address) — with its DOS extenders, staged on a bootable FreeDOS image (33,554,432 bytes) along with two intermediate images: a temporary ROM and an empty SBR. Machine prep matters as much as the commands:

• Boot mode: the DOS tools will not run under UEFI — F2 Setup, Boot Mode = BIOS/Legacy.
• Power: a full flea-power drain first (power off, mains out, hold the power button 20 seconds).
• Drives: pull the SAS caddies — nothing should sit on the bus while the card has no firmware.
• Identity first: step 0 dumps the controller inventory, including the one value that can never be recovered after the flash — the SAS address.

The sequence, each step verified on the bench:

Step	What it does
0 — inventory	Dump identity: product name, firmware build, and the SAS address.
1 — temporary ROM	Flash an intermediate ROM so the card still answers on the PCI bus. Reboot. The POST stalls 3–10 minutes, then reports the card has no bootable firmware — that is expected.
2 — erase	Empty the controller flash (SBR) so the new firmware writes into a blank region. Reboot.
3 — flash	Write HBA330.fw and the card BIOS ROM.
4 — SAS address	Write the recorded SAS address back, then sas3flsh -list to verify the card reports Firmware: IT.

The SAS address deserves its own paragraph. It is the card's 64-bit world-wide identifier on the SAS fabric, reported in every IDENTIFY address frame — the controller's address, not the drives'. It lives in its own flash region, which is exactly why a clean flash destroys it and no tool can reconstruct it. The bench card's address was 0x5f402700e584a300: captured in step 0, written back in step 4, and confirmed when the kernel logged sas_addr(0x5f402700e584a300) at boot. Lose it and the controller comes up with a wrong address, and any record keyed to the controller's SAS address no longer matches the hardware.

Two more things to know before trying this anywhere. First, it is a one-way conversion: the HBA330 firmware cannot be flashed back to the RAID firmware directly, though Dell's PERC H330 RAID firmware updater can restore RAID mode if it is ever needed. Second, the iDRAC may notice: with the RAID firmware gone, the BMC can no longer read drive temperatures and may hold the fans higher than before (PCI3018 in the lifecycle log). On a bench that is acceptable; on a production server, know about it before you flash.

What passthrough changed

First boot after the flash, the card came up under mpt3sas with all eight phys enabled and every drive on its own /dev/sdX:

• Identity — serials read straight from VPD page 0x80, instead of a controller-invented string.
• Health — SMART from SCSI LOG SENSE: health status, current temperature, accumulated power-on hours. (SAS drives have no ATA attribute table, which is exactly why a RAID layer that hides LOG SENSE hides the drive's health with it.)
• Erasure — the SANITIZE opcode probed per drive with sg_opcodes, and issued where supported.

The bench showed both outcomes side by side on one controller. The Toshiba AL14SXL30EN advertises SANITIZE, so tScrub ran a firmware-level overwrite sanitise — a Purge, with live progress and ETA read from the drive's own sense data. The AL13SXL300N, in the same bay layout, does not support SANITIZE, so it got a software overwrite recorded honestly as Clear. Passthrough is what makes that distinction visible and reportable at all; behind the RAID firmware both drives would have been one virtual disk and neither method would exist.

The captured SMART told the same story about the drives themselves: the AL14SXL30EN reported 67,285 power-on hours at 32 °C with four grown defects — the kind of per-drive fact a destruction report should contain, and that no array layer can provide.

What about the card's "Non-RAID" disk mode?

The H330 does offer a way to mark physical disks as Non-RAID from its Ctrl-R utility, which exposes them to the OS without building an array. It is not the same as IT firmware. Those disks are still presented through the megaraid_sas RAID driver's translation layer rather than as raw SAS devices — a mediated path that is not guaranteed to pass every CDB (VPD, LOG SENSE, SANITIZE) unmodified. The crossflash removes the translation layer entirely: the controller stops interpreting commands and just forwards them. For erasure evidence, the raw path is the one that matters.

Rules we follow

• tScrub never breaks an array. If a drive is a RAID member, it is flagged on the row and the operator is told to dismantle the array in the controller BIOS first. Erasure is always per physical drive, never a logical volume. A drive behind true IT firmware is not an array member, so no dismantling applies.
• Firmware for a flash comes from the vendor. A random firmware file from a forum zip is not how you flash a controller that will produce destruction certificates.
• Identity first. The SAS address and serials are captured before anything is erased or flashed, and verified afterwards.

FAQ

Do I need to convert every RAID card before wiping?

No. Many controllers offer a JBOD or passthrough mode in their own setup utility, and tScrub flags RAID members rather than touching them. Conversion is the path for cards with no passthrough mode at all, like the RAID-only H330.

Is the converted card still supported by the vendor?

The card runs Dell's own HBA330 firmware after the conversion, so the firmware is the vendor's; the conversion procedure itself is a field operation with no vendor blessing, which is why we document it and keep the checksum-verified firmware.

What does the erasure report say after a conversion?

The report is per drive, exactly as on any other machine: model, serial, method, NIST level, outcome — plus the SMART health read from the drive itself. The conversion only changes whether the drives are reachable in the first place.

What happens if the SAS address is lost?

The drives still enumerate and erase normally — the address belongs to the controller, not the drives — but the card then presents a different SAS address than the one the machine originally had, so records keyed to the controller's address no longer match the hardware. Record it before the erase step; it is in the inventory dump and on the card label.