Guide: Reviving Toshiba / Kioxia PX02 & PX05 drives

[Fritz]

Can't speak for everyone but I'll never buy another Toshiba product after this unnecessary Shit Show.

 

[archiethemonger]

@Fritz Although the problem was caused by Toshiba writing shitty firmware, the lack of a fix is not their fault. Toshiba legally can't do anything to help customers since they sold off their SSD intellectual property to Kioxia. Unfortunately, Kioxia is not willing to help with vendor-branded drives on a direct-to-consumer basis.

It's likely the legal contract that Kioxia has inherited may not allow them to circumvent the vendors to release a fix for all drives (likely to avoid trademark infringement, since the firmware would have the vendor's name in the firmware header/footer).

Ultimately, the lack a fix really falls on some vendors (e.g. Dell) for waiting on individual corporate customers to pay for a service contract to "merge in" the fix on each model number so they can rake in some extra cash.

 

[Fritz]

Mine is a Genuine Toshiba, not a vendor branded drive so I not only hold them responsible for this mess but also for the legal quagmire that created it. If Dell, Lenovo and whoever else vendor branded these drives has the ability to fix this problem but chose not to because of political and/or financial reasons then they're even more guilty because their contribution was premeditated. So screw them all.

 

[archiethemonger]

You might want to try to email Kioxia's customer support. They might be willing to give you a FW update for your Toshiba branded drive (based on their excuse that they wouldn't help me strictly due to it being a vendor branded drive).

 

[user_name]

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

I'm considering trying this firmware on a working Dell PX05SMB080Y later this week. Is it expected that this firmware will contain the 70k hours fix? It seems those who have tried the PX05.bin and PX05-SED.bin firmwares on the Y variants haven't had much luck, so I'm debating between trying this versus Dell's AS10 firmware.

 

[LumpyRareHawk]

I'm considering trying this firmware on a working Dell PX05SMB080Y later this week. Is it expected that this firmware will contain the 70k hours fix? It seems those who have tried the PX05.bin and PX05-SED.bin firmwares on the Y variants haven't had much luck, so I'm debating between trying this versus Dell's AS10 firmware.

Don't botter with AS10, we already know it doesn't fix the issue.

For AU0F, my disks haven't reached 70k hours yet so can't say. Will need someone that already reached it to try it.

 

[nmap]

Trying to flash my drives with TrueNAS Core and Ubuntu Server 24 with an H710P flashed to IT mode via your other thread:

root@debian:/media/user/64gb/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=220 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 79 00 00 1d 32 29 26 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 79 00  00 1d 32 29 26 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

 

[nmap]

Just tried on a Debian Live ISO, same results

 

[Methylzero]

Hello!
Does anyone know if the PX05SRB 500GB SERIES is also affected by this bug?
I have a PX05SRB100 and it is working perfectly at the moment, but I cannot seem to be able to find the POH counter.
Does anyone know which sg_logs page contains the power on time?
The drive has PX05SRB100 on the label but reports itself as a SLB5F-M960SS, firmware T40A

Thanks!

 

[MaHeSi84]

Hi Jon,


first off, thank you for the PX revival guide and the AU0F firmware you pulled from the Compellent ISO. It got me a lot further than the public package.


I have eight Toshiba PX05SRB096Y (960GB SAS, Dell DP/N 0CN8KY) pulled from a Dell SCv2020. Seven died with the classic ~70k POH bug, reporting 0 bytes and ASC=44/ASCQ=d1 on every command. One spare with fewer hours still works fine. Running firmware on the dead ones is AU05.


Progress so far:

• PX05.bin and PX05-SED.bin → rejected with "Digital signature validation failure" (expected, NetApp firmware)
• Your FMDELPX05SRB384Y_AU0F_NS → my model PX05SRB096Y is listed in the Dell header (ref 105732), so the firmware is correct for my drive
• I trimmed the 1024-byte (0x400) Dell wrapper so the file now starts cleanly at the Toshiba "PM04DHWF" header (verified, version P4M:41:0F)

But the flash itself won't complete:

• Mode 5: returns immediately with Sense key Hardware Error, ASC=19 ASCQ=81 (defect list error). Sense: 72 04 19 81 ... 79 00 00 1d 32 24 1f 00 00 03 e0 00 53 07
• Mode 7 (on a different drive): hangs for ~5 minutes, then DID_TIME_OUT (transport error)

It really looks like the bricked state itself blocks the write-buffer path. Is there a reset/unlock step needed before flashing on an already-bricked drive (as opposed to flashing preventively before they hit 0 bytes)? Or a different procedure for drives already in the 0-byte state?

sg_write_buffer -vvvvv -m 5 --in AU0F_clean.bin /dev/sg1
open /dev/sg1 with flags=0x802
tried to read 8388608 bytes from AU0F_clean.bin, got 1215488 bytes
will write 1215488 bytes
sending single write buffer, mode=0x5, mpsec=0, id=0, offset=0, len=1215488
    Write buffer cdb: [3b 05 00 00 00 00 12 8c 00 00]
    Write buffer parameter list (first 256 bytes):
50 4d 30 34 44 48 57 46  0d 0a 0d 0a 54 68 75 72
73 64 61 79 2c 20 41 75  67 75 73 74 20 32 39 2c
20 32 30 31 39 20 31 34  3a 30 34 3a 31 31 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 34  31 3a 30 46 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 20 20 0d 0a 1a
10 00 00 00 41 0f 01 00  03 00 00 00 00 8c 12 00
check_file_type: file descriptor is sg device
      duration=4 ms
Write buffer:
Descriptor format, current; Sense key: Unit Attention
Additional sense: Microcode has been changed
  Descriptor type: Vendor specific [0x80]
    00 3b 41 0f 01 00 00 00 00 00 00 00 79 00 00 1d 32 24 20 00 00 00 00 00
    53 07 00 00 00 00
 Raw sense data (in hex), sb_len=40, calculated_len=40
        72 06 3f 01 00 00 00 20  80 1e 00 3b 41 0f 01 00
        00 00 00 00 00 00 79 00  00 1d 32 24 20 00 00 00
        00 00 53 07 00 00 00 00
Write buffer failed: Unit attention, type: sense key

Hardware: LSI SAS 9300-8i in IT mode (FW v8.37), SystemRescue 13. Happy to provide any logs and report results back for the thread.


Thanks a lot