Guide: Reviving Toshiba / Kioxia PX02 & PX05 drives

[aiches]

Hi,
I´m using 4 PX05SRB384 disks from a HITACHI VANTAGE storage in my HP DL380 G9 server. 3 of them are dead in case of 70.000 hours issue. Does anyone has a firmware update for this model:

=== START OF INFORMATION SECTION ===
Vendor: TOSHIBA
Product: SLB5F-M3R8SS
Revision: T406
Compliance: SPC-4
User Capacity: 3,840,755,982,336 bytes [3.84 TB]
Logical block size: 512 bytes
Physical block size: 4096 bytes
LU is resource provisioned, LBPRZ=1
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Logical Unit id: 0x58ce38ee201b7081
Serial number: SUE02VVG
Device type: disk
Transport protocol: SAS (SPL-3)
Local Time is: Fri Jun 12 10:19:29 2026 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Disabled
Temperature Warning: Disabled or Not Supported

 

[TheCodeLife]

I have what I hope is good news for some out there. I hit 70,000 hours today on one of my PX05 3.84TB drives on firmware revision RC4F. The drive is still working even after a reboot of the server. Hopefully others with this firmware version can breathe a sigh of relief.

 

[ajhieb]

UPDATE: firmware needs to be vendor specific, the below are for netapp firmwares, eg MS02, MS03, MS04. Have other vendor firmwares but need to get them organized and trimmed

PX02 SED Models:

- PX02SMU020
- PX02SMU040
- PX02SMU080
- PX02SMQ160

sg_write_buffer -vvvvv -m 5 --in PX02-SED.bin /dev/sg0

I just became aware of this thread yesterday. I can't thank you enough. I spent most of my weekend fixing 16 bricked PX02SMQ160 drives. Also got the DIF stuff sorted so they're happy on TrueNAS Scale (I'd had them on Core prior to them hitting the log limit) I'm glad I hung on to them.

My magic combo was:

sg_write_buffer -vvvvv -m 5 --in /mnt/usb/Toshiba/PX02-SED.bin /dev/sg1
<shutdown, boot>

sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID <I used google-lens to avoid unnecessary squinting to put the PSID here> /dev/sda
sg_format -v --format --fmtpinfo=0 /dev/sg1

Again, you have my enduring gratitude.

 

[nmap]

I just became aware of this thread yesterday. I can't thank you enough. I spent most of my weekend fixing 16 bricked PX02SMQ160 drives. Also got the DIF stuff sorted so they're happy on TrueNAS Scale (I'd had them on Core prior to them hitting the log limit) I'm glad I hung on to them.

My magic combo was:

sg_write_buffer -vvvvv -m 5 --in /mnt/usb/Toshiba/PX02-SED.bin /dev/sg1
<shutdown, boot>

sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID <I used google-lens to avoid unnecessary squinting to put the PSID here> /dev/sda
sg_format -v --format --fmtpinfo=0 /dev/sg1

Again, you have my enduring gratitude.

How bricked were they? Showing at as 0 bytes or not at all?
Thanks!

 

[MaHeSi84]

I see there has been some further progress regarding bricked hard drives.

Has anyone found a solution for the SRB-Y models yet? (DELL specific)

Unfortunately, I’ve already ruined two drives trying to desolder IC10—which is partially glued down—to read it directly. But without success

 

[ajhieb]

How bricked were they? Showing at as 0 bytes or not at all?
Thanks!

I had 16 showing 0 bytes and one that was an earlier guinea pig, that I truly bricked trying to force some dell firmware onto, well before I discovered this thread. I'm not hopeful for that one as it seems utterly unresponsive and doesn't even get a "ready" led on the backplane.

 

[nmap]

I had 16 showing 0 bytes and one that was an earlier guinea pig, that I truly bricked trying to force some dell firmware onto, well before I discovered this thread. I'm not hopeful for that one as it seems utterly unresponsive and doesn't even get a "ready" led on the backplane.

Thank you! I'll have to give this another shot soon, fingers crossed!

 

[aiches]

The firmware for the SLB5F-M3R8SS variant must be on Hitachi Vantara Microcode Update for VSP systems or on HPE XP8 firmware wich is a branded Hitachi Vantara VSP 5000. Maybe that anyone has access to this software.

 

[nmap]

I've grabbed a new card off ebay to try and flash these. Sadly, I'm still getting the same errors as before.
These are from a Nutanix appliance if that makes any difference.

Currently using a LSI SAS2308 PCI-Express Fusion-MPT SAS-2 in IT mode

root@ubuntu-server:/Toshiba-PX-Firmware# sg_write_buffer -vvvvv -m 5 --in PX05.bin /dev/sg0
open /dev/sg0 with flags=0x802
tried to read 8388608 bytes from PX05.bin, got 1173504 bytes
will write 1173504 bytes
sending single write buffer, mode=0x5, mpsec=0, id=0, offset=0, len=1173504
    Write buffer cdb: [3b 05 00 00 00 00 11 e8 00 00]
    Write buffer parameter list (first 256 bytes):
50 4d 30 34 44 48 57 46  0d 0a 0d 0a 54 75 65 73
64 61 79 2c 20 53 65 70  74 65 6d 62 65 72 20 32
38 2c 20 32 30 32 31 20  31 39 3a 33 30 3a 30 36
20 62 79 74 73 62 67 6c  65 0d 0a 43 6f 70 79 72
69 67 68 74 20 28 43 29  20 54 4f 53 48 49 42 41
20 43 4f 52 50 4f 52 41  54 49 4f 4e 2e 0d 0a 41
6c 6c 20 72 69 67 68 74  73 20 72 65 73 65 72 76
65 64 2e 0d 0a 50 34 4d  3a 37 37 3a 30 36 3a 30
31 3a 30 30 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 0d 0a 1a
00 00 00 00 77 06 01 00  03 00 00 00 00 e8 11 00
check_file_type: file descriptor is sg device
      duration=221 ms
Write buffer:
Descriptor format, current; Sense key: Illegal Request
Additional sense: Invalid field in parameter list
  Descriptor type: Vendor specific [0x80]
    00 3b 01 03 01 00 00 00 00 00 00 00 78 00 00 1d 33 31 2e 00 00 00 00 00
    55 09 00 00 00 00
Raw sense data (in hex), sb_len=40, calculated_len=40
        72 05 26 00 00 00 00 20  80 1e 00 3b 01 03 01 00
        00 00 00 00 00 00 78 00  00 1d 33 31 2e 00 00 00
        00 00 55 09 00 00 00 00
Write buffer failed: Illegal request, Invalid field in parameter list, type: sense key + asc,ascq=0x

smartctl -a /dev/sg0 doesn't look good

=== START OF INFORMATION SECTION ===
Vendor:               TOSHIBA
Product:              PX05SRB384
Revision:             0103
Compliance:           SPC-4
LU is resource provisioned, LBPRZ=1
Rotation Rate:        Solid State Device
Form Factor:          2.5 inches
Logical Unit id:      0x50000397ac8894e9
Serial number:        3740A03RTQYD
Device type:          disk
Transport protocol:   SAS (SPL-4)
Local Time is:        Sun Jul 12 23:36:05 2026 UTC
device Test Unit Ready  [medium or hardware error (serious)]

 

[bruto000]

hi, I also have an IBM disk PX05SRB384, this disk has its own IBM firmware with the number 6402, on the ibm website there is an explanation that an upgrade to firmware 6406 is required, it can be downloaded if you have a stromwize license: Required drive firmware upgrade for 1.92 TB and 3.84 TB Tier 1 Flash drives with 6402 firmware The firmware contains the file: https://support.lenovo.com/us/en/do...ocode-6099-20200821-storwize-v3700-for-lenovo or similar, the problem is that I can't open the file, it's not a rar, zip, archive, you need to extract the firmware from this file.



=== START OF INFORMATION SECTION ===
Vendor: IBM-D051
Product: PX05SRB384
Revision: 6402
Compliance: SPC-4
LU is resource provisioned, LBPRZ=1
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Logical Unit id: 0x500003979c900f8d
Serial number: 27S0A01WTQJE
Device type: disk
Transport protocol: SAS (SPL-4)
Local Time is: Wed Sep 24 18:57:43 2025 CEST
device Test Unit Ready [medium or hardware error (serious)]
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.


 

[nmap]

I've grabbed a new card off ebay to try and flash these. Sadly, I'm still getting the same errors as before.
These are from a Nutanix appliance if that makes any difference.
Currently using a LSI SAS2308 PCI-Express Fusion-MPT SAS-2 in IT mode

Bumping this

 

[airlia101]

I just picked up an ebay PX05SVQ192B, for a good used price, but ... it seems to only read/write the first 64GB? Could this be a firmware issue, rather than a dying NAND controller or flash memory?
This thread gave me some hope that several common failures could be solved -- but I've run into an uncommon error.

The drive shows up, displays expected capacity, and passes short and long SMART tests. No errors or defects listed in smartctl.
Then I tried to reformat, and it failed. I ran a badblocks test, and it only writes 64M blocks (62915584) before running into endless bad blocks. Several subsequent badblocks tests (read-only, write, after power cycles...) hit that same first block number. And, a dd read stopped at 64166559744 bytes before input/output errors. These seem like suspiciously round numbers...

Other observations:
- Poweron hours are reported as just 28,500
- FW revision reported as "0503"
- Each badblocks test accumulates non-medium errors in SMART
- the "gigabytes processed" for read and write have increased with all these tests. I didn't think to check if they match up with these 64gb increments, though.


I thought this almost sounded like a cable/interface/HBA issue -- my home server uses a SAS2 SAS2308 card. But I just got to try this out on a Dell system at work, and badblocks failed at the same address.

What's the chances this is some sort of firmware or even formatting issue? Any advice?

(thank you to all the contributors to this thread -- you're doing wonders keeping firmware files available, and rejuvenating hardware!)

 

[Fritz]

Sounds like you've been scammed.

 

[LumpyRareHawk]

I just picked up an ebay PX05SVQ192B, for a good used price, but ... it seems to only read/write the first 64GB? Could this be a firmware issue, rather than a dying NAND controller or flash memory?
This thread gave me some hope that several common failures could be solved -- but I've run into an uncommon error.

The drive shows up, displays expected capacity, and passes short and long SMART tests. No errors or defects listed in smartctl.
Then I tried to reformat, and it failed. I ran a badblocks test, and it only writes 64M blocks (62915584) before running into endless bad blocks. Several subsequent badblocks tests (read-only, write, after power cycles...) hit that same first block number. And, a dd read stopped at 64166559744 bytes before input/output errors. These seem like suspiciously round numbers...

Other observations:
- Poweron hours are reported as just 28,500
- FW revision reported as "0503"
- Each badblocks test accumulates non-medium errors in SMART
- the "gigabytes processed" for read and write have increased with all these tests. I didn't think to check if they match up with these 64gb increments, though.


I thought this almost sounded like a cable/interface/HBA issue -- my home server uses a SAS2 SAS2308 card. But I just got to try this out on a Dell system at work, and badblocks failed at the same address.

What's the chances this is some sort of firmware or even formatting issue? Any advice?

(thank you to all the contributors to this thread -- you're doing wonders keeping firmware files available, and rejuvenating hardware!)

Yeah, you might have been scammed...

Not really the same problem as in this thread so I would suggest you create a new thread and post the full smart output and pictures of the drive so other people can help with this specific issue.

 

[LumpyRareHawk]

apparently 1MB is too large to attach now so here's a link https://fohdeesha.com/data/other/FMDELPX05SRB384Y_AU0F_NS.zip

the file in the zip was pulled directly from the compellent ISO, I imagine it'll prolly have some weird compellent header data you'll need to trim out if you're gunna flash with sg_utils etc

edit: just actually read your previous replies and you're already on this version lol. yes it's fixed

One of my AU0F SSD just passed the 70,000 hour mark and I confirm it's still working after an unplug/replug.
So to anyone having a Y SSD that is not on AU0F and is not locked, I would suggest to try to flash this firmware before it's too late.

I see there has been some further progress regarding bricked hard drives.

Has anyone found a solution for the SRB-Y models yet? (DELL specific)

Unfortunately, I’ve already ruined two drives trying to desolder IC10—which is partially glued down—to read it directly. But without success

Can't help for your unlock but AU0F is ok if flashed before the disk lock itself.
Edit: Not sure if you saw this, but on the Dell site they say:
"it is imperative that a Dell SAS HBA controller is used when the drives are in a locked state. This is because the PERC controller may block any firmware update actions on locked drives."
PM2, PM2+, PM2R SSDs drives locking after 70000 Power On Hours

 

[Fritz]

Is AUY0F for dell branded drives only?

 

[airlia101]

I just picked up an ebay PX05SVQ192B, for a good used price, but ... it seems to only read/write the first 64GB? Could this be a firmware issue, rather than a dying NAND controller or flash memory?

Thanks y'all who replied; no it wasn't a scam, just a clueless seller. And a clueless me, at first.

Windows gave me a clue -- trying to format the disk from GUI, it failed and popped up a message "is it read only?" Which sounded like either a completely failed SSD... or, an encrypted SED lock-out. Fingers crossed...
I tried doing a PSID-revert with sedutil, and it seems to have succeeded! Full disk passed 4x badblocks passes!

This was strange because I'd thought encryption would have applied to the whole disk, not just part of it. It's a complete guess but perhaps there were two partitions; the first was plain and the second encrypted. Wish I paid a bit more attention before blowing away the original partition table, but I was agog at the seller not wiping it first

Anyway, replying here because this was also an adventure in "reviving a PX05 drive". Perhaps it'll help someone else in the future.

Pics: HDTune error check before, and after:

 

[joerambo]

This was strange because I'd thought encryption would have applied to the whole disk, not just part of it. It's a complete guess but perhaps there were two partitions; the first was plain and the second encrypted.

It might have been NVME namespaces or even some vendor specific NVME "extension" that locked out part of the disk. Partitions operate at "OS" level and would not impact blocks coming out of drive.