Guide: Reviving Toshiba / Kioxia PX02 & PX05 drives

BackupProphet · Oct 30, 2025

It looks like a generic Toshiba. I've been trying to find images on Ebay of the same SSD with the same series of firmware version on Ebay. But without success.

Code:

sudo sg_inq /dev/sg1
standard INQUIRY:
  PQual=0  PDT=0  RMB=0  LU_CONG=0  hot_pluggable=0  version=0x06  [SPC-4]
  [AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=1  Resp_data_format=2
  SCCS=0  ACC=0  TPGS=0  3PC=0  Protect=1  [BQue=0]
  EncServ=0  MultiP=1 (VS=0)  [MChngr=0]  [ACKREQQ=0]  Addr16=0
  [RelAdr=0]  WBus16=0  Sync=0  [Linked=0]  [TranDis=0]  CmdQue=1
  [SPI: Clocking=0x0  QAS=0  IUS=0]
    length=96 (0x60)   Peripheral device type: disk
 Vendor identification: TOSHIBA
 Product identification: PX02SMU040     
 Product revision level: 0802


sudo sg_inq -p di /dev/sg1
VPD INQUIRY: Device Identification VPD page
Designation descriptor number 1, descriptor length: 12
designator_type: NAA, code_set: Binary
associated with the Addressed logical unit
NAA 5, AOI: 0x39
Vendor Specific Identifier: 0x67c8a8580
[0x500003967c8a8580]
Designation descriptor number 2, descriptor length: 12
transport: Serial Attached SCSI Protocol (SPL-4)
designator_type: NAA, code_set: Binary
associated with the Target port
NAA 5, AOI: 0x39
Vendor Specific Identifier: 0x67c8a8582
[0x500003967c8a8582]
Designation descriptor number 3, descriptor length: 8
transport: Serial Attached SCSI Protocol (SPL-4)
designator_type: Relative target port, code_set: Binary
associated with the Target port
Relative target port: 0x1
Designation descriptor number 4, descriptor length: 12
transport: Serial Attached SCSI Protocol (SPL-4)
designator_type: NAA, code_set: Binary
associated with the Target device that contains addressed lu
NAA 5, AOI: 0x39
Vendor Specific Identifier: 0x67c8a8581
[0x500003967c8a8581]
Designation descriptor number 5, descriptor length: 28
transport: Serial Attached SCSI Protocol (SPL-4)
designator_type: SCSI name string, code_set: UTF-8
associated with the Target device that contains addressed lu
SCSI name string:
naa.500003967C8A8581

therem · Nov 2, 2025

fohdeesha said:
UPDATE: currently a known issue with IBM/lenovo versions not taking these vanilla firmwares - working on it

TLDR: these series of drives have a 70k power on hours bug where after this amount of time, they brick themselves and become useless, with no access to your data. Toshiba fixed this in firmware which revives the drive and gets your data back too, but they refused to send it to anyone, and now are claiming they don't have access to it anymore. I've seen people with ~100 of these things now acting as door stops, here's how to revive them and get your drives back. shame on these shit companies who contribute to a massive e-waste issue, I highly recommend not purchasing Toshiba / Kioxia in the future

https://fohdeesha.com/docs/store/Toshiba-PX-Firmware.zip
# If you don't have it already:
apt install sg3-utils
# Flashing on *bsd (like truenas core) probably won't work in my experience due to weird CAM memory mapping shortfalls
# These commands all assume your dead drive is /dev/sg0, confirm that with smartctl -a /dev/sg0. It might be sg1 sg2 etc
# These are pretty safe as they confirm the firmware matches type and signature before flashing
# If it works you should get no errors
# After flashing remove and replug, or otherwise fully power cycle drive to take effect (not just warm server reboot)
# Should work regardless of OEM / vendor

PX02 Regular Models:

- PX02SMF020
- PX02SMF040
- PX02SMF080
- PX02SMB160

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

PX02 SED Models:

- PX02SMU020
- PX02SMU040
- PX02SMU080
- PX02SMQ160

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

PX05 Regular Models:

- PX05SVB040
- PX05SVB080
- PX05SVB160
- PX05SVB320
- PX05SVB048
- PX05SVB096
- PX05SVB192
- PX05SVB384
- PX05SRB048
- PX05SRB096
- PX05SRB192
- PX05SRB384
- PX05SHB020
- PX05SHB040
- PX05SHB080
- PX05SHB160
- PX05SMB040
- PX05SMB080
- PX05SMB160
- PX05SMB320

sg_write_buffer -vvvvv -m 5 --in PX05.bin /dev/sg0

PX05 SED Models:
- PX05SVQ040
- PX05SVQ080
- PX05SVQ160
- PX05SVQ320
- PX05SVQ048
- PX05SVQ096
- PX05SVQ192
- PX05SVQ384
- PX05SRQ048
- PX05SRQ096
- PX05SRQ192
- PX05SRQ384
- PX05SHQ020
- PX05SHQ040
- PX05SHQ080
- PX05SHQ160
- PX05SMQ040
- PX05SMQ080
- PX05SMQ160
- PX05SMQ320

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

----------------
- FIPS models end with B, need signed image, contact me jon@fohdeesha.com
- If your exact model isn't on here, contact me. I know models ending in Y, like PX05SMB080Y, are SIE (secure instant erase) models, they may take the SED firmware, not sure. try and report back
- toshiba: suck my ass

Many thanks for this amazing job

Just would like to share the way I managed to reuse DELL UNITY EMC3200 3.2TB SSDs (Toshiba PX05SRB384) like any standard SAS 512e SSD drives in any server, any controller and any OS :

1) First re-format the drive to 512B/4K standard sector size : https://forums.servethehome.com/index.php?threads/how-to-reformat-hdd-ssd-to-512b-sector-size.4968/

2) Check for firmware update to avoid this f*** 70k power-on hours wall bug. The provided FW pack files

https://fohdeesha.com/docs/store/Toshiba-PX-Firmware.zip

and

https://fohdeesha.com/data/other/test.zip

did not match my drives DELL/EMC Firmware (QC4F) so the update process failed. BUT I found QC4F is actually the latest existing firmware version for those drives as per this UNITY document (Jul 23, 2024). So I guess my drives should be safe. Fingers crossed

Code:

sudo sg_scan  -i
/dev/sg0: scsi0 channel=0 id=0 lun=0 [em]
    SMI       USB DISK          1100 [rmb=1 cmdq=0 pqual=0 pdev=0x0]
/dev/sg1: scsi1 channel=0 id=0 lun=0
    HP        P440ar            7.00 [rmb=0 cmdq=1 pqual=0 pdev=0xc]
/dev/sg2: scsi1 channel=0 id=1 lun=0
    TOSHIBA   5SVB320C EMC3200  QC4F [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg3: scsi1 channel=0 id=2 lun=0
    TOSHIBA   5SVB320C EMC3200  QC4F [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg4: scsi1 channel=0 id=3 lun=0
    TOSHIBA   5SVB320C EMC3200  QC4F [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg5: scsi1 channel=0 id=4 lun=0
    TOSHIBA   5SVB320C EMC3200  QC4F [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg6: scsi1 channel=0 id=5 lun=0
    HP        P440ar            7.00 [rmb=0 cmdq=0 pqual=0 pdev=0xd]

Code:

sudo sg_write_buffer -vvvvv -m 5 --in PX05.bin /dev/sg2
found sg_bsg_major=244
found sg_nvme_char_major=243
open /dev/sg2 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
ioctl(SG_IO v3) failed: Invalid argument (errno=22)
Write buffer: pass-through os error: Invalid argument
Write buffer failed: OS error: Invalid argument

Code:

sudo sg_write_buffer -vvvvv -m 5 --in 1.bin /dev/sg2
found sg_bsg_major=244
found sg_nvme_char_major=243
open /dev/sg2 with flags=0x802
tried to read 8388608 bytes from 1.bin, got 1117184 bytes
will write 1117184 bytes
sending single write buffer, mode=0x5, mpsec=0, id=0, offset=0, len=1117184
    Write buffer cdb: [3b 05 00 00 00 00 11 0c 00 00]
    Write buffer parameter list (first 256 bytes):
50 58 30 35 44 48 57 46  0d 0a 0d 0a 54 68 75 72
73 64 61 79 2c 20 4d 61  79 20 30 38 2c 20 32 30
32 35 20 31 36 3a 30 30  3a 33 37 20 62 79 74 73
62 67 6c 65 0d 0a 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
50 35 4d 3a 37 32 3a 30  37 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 0d 0a 1a
20 20 20 20 20 20 20 20  4e 41 35 36 00 00 00 00
40 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 08 11 00
40 00 00 00 72 07 01 00  04 00 00 00 00 0c 11 00
check_file_type: file descriptor is sg device
ioctl(SG_IO v3) failed: Invalid argument (errno=22)
Write buffer: pass-through os error: Invalid argument
Write buffer failed: OS error: Invalid argument

Code:

sudo sg_write_buffer -vvvvv -m 5 --in 2.bin /dev/sg2
found sg_bsg_major=244
found sg_nvme_char_major=243
open /dev/sg2 with flags=0x802
tried to read 8388608 bytes from 2.bin, got 1179648 bytes
will write 1179648 bytes
sending single write buffer, mode=0x5, mpsec=0, id=0, offset=0, len=1179648
    Write buffer cdb: [3b 05 00 00 00 00 12 00 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 32 38 3a 34 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 32 3a 30 35 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 72 05 01 00  03 00 00 00 00 00 12 00
check_file_type: file descriptor is sg device
ioctl(SG_IO v3) failed: Invalid argument (errno=22)
Write buffer: pass-through os error: Invalid argument
Write buffer failed: OS error: Invalid argument

Code:

sudo smartctl -a /dev/sg2
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.10.10-1-liquorix-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               TOSHIBA
Product:              5SVB320C EMC3200
Revision:             QC4F
Compliance:           SPC-4
User Capacity:        3.200.824.377.344 bytes [3,20 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:      0x58ce38ee2039e3ad
Serial number:        xxxxxxx
Device type:          disk
Transport protocol:   SAS (SPL-4)
Local Time is:        Sun Nov  2 10:02:37 2025 CET
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Percentage used endurance indicator: 26%
Current Drive Temperature:     29 C
Drive Trip Temperature:        63 C

Accumulated power on time, hours:minutes 56291:58
Manufactured in week 21 of year 2018
Specified cycle count over device lifetime:  33554432
Accumulated start-stop cycles:  25
Elements in grown defect list: 0

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0        0         0         0          0    2463598,728           0
write:         0        0         0         0          0     659560,139           0
verify:        0        0         0         0          0     216696,973           0

Non-medium error count:      630

No Self-tests have been logged

Code:

cat /etc/debian_version
12.12

NOTE : P440ar in HBA mode

Thanks again mate.

TheCodeLife · Nov 4, 2025

I bought a bunch of used PX05SRB384 drives a few years ago that appear to be from Toshiba, but I have been unsuccessful with the firmware update.

I am running the latest version of Proxmox on a H730p in HBA mode. When I try updating the drive, I get the following message:

Code:

g_write_buffer -vvvvv -m 5 --in PX05.bin /dev/sg3
open /dev/sg3 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
ioctl(SG_IO v3) failed: Invalid argument (errno=22)
Write buffer: pass-through os error: Invalid argument
Write buffer failed: OS error: Invalid argument

The drive information is from smartctl is this:

Code:

smartctl -a /dev/sg3
smartctl 7.4 2024-10-15 r5620 [x86_64-linux-6.14.11-4-pve] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               TOSHIBA
Product:              5SRB384CCLAR3840
Revision:             RC4F
Compliance:           SPC-4
User Capacity:        3,840,774,504,448 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:      0x58ce38ee2022eba5
Serial number:        3810A0FGT3EE
Device type:          disk
Transport protocol:   SAS (SPL-4)
Local Time is:        Tue Nov  4 21:28:01 2025 EST
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Percentage used endurance indicator: 26%
Current Drive Temperature:     23 C
Drive Trip Temperature:        63 C

Accumulated power on time, hours:minutes 64416:18
Manufactured in week 09 of year 2018
Specified cycle count over device lifetime:  33554432
Accumulated start-stop cycles:  25
Elements in grown defect list: 1

All of my drives appear to have the same revision, but I haven't been able to find any information on it. Perhaps no update is needed, but I am a bit anxious as I have a bunch of these drives and I'm concerned they will fail since they are near the 70,000 hour mark. Any help would be greatly appreciated!

fohdeesha · Nov 4, 2025

TheCodeLife said:

I bought a bunch of used PX05SRB384 drives a few years ago that appear to be from Toshiba, but I have been unsuccessful with the firmware update.

I am running the latest version of Proxmox on a H730p in HBA mode. When I try updating the drive, I get the following message:

Code:

g_write_buffer -vvvvv -m 5 --in PX05.bin /dev/sg3
open /dev/sg3 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
ioctl(SG_IO v3) failed: Invalid argument (errno=22)
Write buffer: pass-through os error: Invalid argument
Write buffer failed: OS error: Invalid argument

The drive information is from smartctl is this:

Code:

smartctl -a /dev/sg3
smartctl 7.4 2024-10-15 r5620 [x86_64-linux-6.14.11-4-pve] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               TOSHIBA
Product:              5SRB384CCLAR3840
Revision:             RC4F
Compliance:           SPC-4
User Capacity:        3,840,774,504,448 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:      0x58ce38ee2022eba5
Serial number:        3810A0FGT3EE
Device type:          disk
Transport protocol:   SAS (SPL-4)
Local Time is:        Tue Nov  4 21:28:01 2025 EST
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Percentage used endurance indicator: 26%
Current Drive Temperature:     23 C
Drive Trip Temperature:        63 C

Accumulated power on time, hours:minutes 64416:18
Manufactured in week 09 of year 2018
Specified cycle count over device lifetime:  33554432
Accumulated start-stop cycles:  25
Elements in grown defect list: 1

All of my drives appear to have the same revision, but I haven't been able to find any information on it. Perhaps no update is needed, but I am a bit anxious as I have a bunch of these drives and I'm concerned they will fail since they are near the 70,000 hour mark. Any help would be greatly appreciated!

I don't recognize that firmware string, but I think you're probably fine. just be sure to have backups in case they do die. As for the flash error, you can't flash these through raid cards like the perc in their pretend HBA mode, you need something with direct vanilla access. It could be proxmox getting in the way, you could try live booting debian or something

TheCodeLife · Nov 5, 2025

Thanks! Is the firmware you provided the latest version? Even if I'm not affected by the 70K hour issue, I know there were some write endurance bugs in some versions of firmware as well. I was already considering replacing the perc with an HBA330 that I can use in IT mode.

Fritz · Nov 14, 2025

I just updated my PX02SMQ160 from MS02 to MS03 using Server 2022 and I did it remotely. So can I assume that MS03 does not have the bug?

TIA

And btw - Thank you very much OP.

BackupProphet · Nov 21, 2025

I also have a PX05SRQ192 that I tried to update, of course it also failed. They are from EMC XtremIO. The firmware on the label is MB42 while the running firmware is PB4B. I think the latest is PB4F?

EasyRhino · Dec 3, 2025

fohdeesha said:
- PX02SMU080

I regret I hadn't seen this thread earlier. I dusted off my two old dusty PX02 drives and gave this a whirl. I suspect these came out of EMC systems, but am not sure. They looked like "generic" Toshiba drives.

Incidentally, when I tried using my old HP H240 HBA, sg_scan and sg_inq didn't even recognize the drives. But my LSI 9400 did. So that was weird.

Before it appears they were on firmware MS01. Fohdeesha's firmare upgraded it to MS03. And they now appear in linux. I haven't quite been able to format them yet becuase it's a truenas box and they are formated with Data Integrity Feature (DIF) and it's time for me to go to bed. But it's still exciting!

EasyRhino · Dec 4, 2025

Also uploading the info for the drive that succeeded as well as a picture of it, for posterity.

and here is what sq_inq showed for the drive BEFORE I did the firmware update:

Code:

admin@nas:~$ sudo sg_inq /dev/sg4
standard INQUIRY:
  PQual=0  PDT=0  RMB=0  LU_CONG=0  hot_pluggable=0  version=0x06  [SPC-4]
  [AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=1  Resp_data_format=2
  SCCS=0  ACC=0  TPGS=0  3PC=0  Protect=1  [BQue=0]
  EncServ=0  MultiP=1 (VS=0)  [MChngr=0]  [ACKREQQ=0]  Addr16=0
  [RelAdr=0]  WBus16=0  Sync=0  [Linked=0]  [TranDis=0]  CmdQue=1
  [SPI: Clocking=0x0  QAS=0  IUS=0]
    length=96 (0x60)   Peripheral device type: disk
 Vendor identification: TOSHIBA
 Product identification: PX02SMU080
 Product revision level: MS01
 Unit serial number: 64Q0A00QT2BA
admin@nas:~$ sudo sg_inq /dev/sg4 -v
    inquiry cdb: [12 00 00 00 24 00]
    inquiry cdb: [12 00 00 00 60 00]
    inquiry cdb: [12 01 00 00 fc 00]
    inquiry cdb: [12 01 80 00 fc 00]
standard INQUIRY:
  PQual=0  PDT=0  RMB=0  LU_CONG=0  hot_pluggable=0  version=0x06  [SPC-4]
  [AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=1  Resp_data_format=2
  SCCS=0  ACC=0  TPGS=0  3PC=0  Protect=1  [BQue=0]
  EncServ=0  MultiP=1 (VS=0)  [MChngr=0]  [ACKREQQ=0]  Addr16=0
  [RelAdr=0]  WBus16=0  Sync=0  [Linked=0]  [TranDis=0]  CmdQue=1
  [SPI: Clocking=0x0  QAS=0  IUS=0]
    length=96 (0x60)   Peripheral device type: disk
 Vendor identification: TOSHIBA
 Product identification: PX02SMU080
 Product revision level: MS01
 Unit serial number: 64Q0A00QT2B

EasyRhino · Dec 4, 2025

additional note, my drives were apparantly SED or Opal secured, and showed locked. My first attempt to reformat to remove DIF gave a drive locked error:

Code:

admin@nas:~$ sudo sg_format --format -v --size=512 /dev/sdg
[sudo] password for admin:
    TOSHIBA   PX02SMU080        MS03   peripheral_type: disk [0x0]
      PROTECT=1
      << supports protection information>>
      Unit serial number: 64Q0A00YT2BA
      LU name: 500003959c894a28
    mode sense(10) cdb: [5a 00 01 00 00 00 00 00 fc 00]
Mode Sense (block descriptor) data, prior to changes:
  Number of blocks=1562824368 [0x5d26ceb0]
  Block size=512 [0x200]

A FORMAT UNIT will commence in 15 seconds
    ALL data on /dev/sdg will be DESTROYED
        Press control-C to abort

A FORMAT UNIT will commence in 10 seconds
    ALL data on /dev/sdg will be DESTROYED
        Press control-C to abort

A FORMAT UNIT will commence in 5 seconds
    ALL data on /dev/sdg will be DESTROYED
        Press control-C to abort
    Format unit cdb: [04 18 00 00 00 00]
Format unit:
Fixed format, current; Sense key: Data Protect
Additional sense: Access denied - no access rights
Format unit command: Data protect, type: sense key; write protected media?
FORMAT UNIT failed

I was able to do a PSID revert with this:

Code:

sudo sedutil-cli --psidrevert PGCK78SYAG9AHJ8JD4NLXG97F8JWJENP /dev/sdg

my second sg_format attempt worked fine:

Code:

admin@nas:~$ sudo sg_format --format -v --size=512 /dev/sdg
    TOSHIBA   PX02SMU080        MS03   peripheral_type: disk [0x0]
      PROTECT=1
      << supports protection information>>
      Unit serial number: 64Q0A00YT2BA
      LU name: 500003959c894a28
    mode sense(10) cdb: [5a 00 01 00 00 00 00 00 fc 00]
Mode Sense (block descriptor) data, prior to changes:
  Number of blocks=1562824368 [0x5d26ceb0]
  Block size=512 [0x200]

A FORMAT UNIT will commence in 15 seconds
    ALL data on /dev/sdg will be DESTROYED
        Press control-C to abort

A FORMAT UNIT will commence in 10 seconds
    ALL data on /dev/sdg will be DESTROYED
        Press control-C to abort

A FORMAT UNIT will commence in 5 seconds
    ALL data on /dev/sdg will be DESTROYED
        Press control-C to abort
    Format unit cdb: [04 18 00 00 00 00]
Format unit command launched without error

Format unit has started
Format unit seems to be successful and finished quickly
FORMAT UNIT Complete

then truenas was able to create a pool.

I currently regret only that I didn't take a photo of the other drive's PSID that is now sitting inside my chassis in the basement.

acesea · Dec 6, 2025

I found this thread and the previous thread at https://forums.servethehome.com/index.php?threads/toshiba-px05srb-ssd-failures.43665/page-4
and just wow Toshiba Kioxia incredible work destroying brand and reputation.

The few affected devices I have are not yet bricked. Does anyone know what firmware version or firmware release dates are required to resolve this bug?

Dell labelled PX05 that had AS03 firmware, the fohdeesha files didnt work but I successfully updated to AS10 using files at this link
Toshiba AS10 for model number(s) PX05SMB320Y, PX05SMB160Y, PX05SMB080Y, PX05SMB040Y, PX05SVB384Y, PX05SVB192Y, PX05SVB096Y, PX05SVB048Y, PX05SRB384Y, PX05SRB192Y, PX05SRB096Y and PX05SRB048Y. | Driver Details | Dell US
firmware support for PX05SMB320Y, PX05SMB160Y, PX05SMB080Y, PX05SMB040Y, PX05SVB384Y, PX05SVB192Y, PX05SVB096Y, PX05SVB048Y, PX05SRB384Y, PX05SRB192Y, PX05SRB096Y and PX05SRB048Y
Dell site shows AS10 Release date 24 Oct 2019
I reviewed the release notes and there's no mention of any bug fix related to this thread. Does anyone know what firmware versions or release dates we should be targeting in order to resolve the " power on hours bug "? I doubt these firmware updates fix the bug since post in the other thread that bricked devices flashed to AS10 did not work anyway. https://forums.servethehome.com/index.php?threads/toshiba-px05srb-ssd-failures.43665/post-449361

Other similar looking dell PX05 with different AV02 firmware and the fohdeesha files don't work and I cannot find any dell website pages or files to update the AV02 firmware. The above dell link to AS10 firmware update does not work on these AV02 firmware drives, and searching I cannot find any other dell updates for AV** firmwares lol.

Fyi quick search I also found PowerEdge: PM2, PM2+, PM2R SSDs drives locking after 70000 Power On Hours | Dell Botswana
which identifies PX03 are affected, not only PX02 and PX05:
"

PM2R	N9PTK	PX03SNF080	800GB
PM2R	0MXR2	PX03SNB160	1.6TB

"
and also identifies:
"
Resolution

Fixed in firmware versions
PM2, Drive Firmware A3B4
PM2+, Drive Firmware A4B4
PM2R, Drive Firmware A5B4
Firmware update Web posted 24th August 2023.
"

Does anyone know what firmware versions or firmware release dates are required to resolve this bug?

Fritz · Dec 6, 2025

I've been trying to find which firmware version fixes this bug too and I can't believe this thread has gone for 2 pages without anybody mentioning.

5mall5nail5 · Dec 6, 2025

acesea said:
I found this thread and the previous thread at https://forums.servethehome.com/index.php?threads/toshiba-px05srb-ssd-failures.43665/page-4
and just wow Toshiba Kioxia incredible work destroying brand and reputation.

The few affected devices I have are not yet bricked. Does anyone know what firmware version or firmware release dates are required to resolve this bug?

Dell labelled PX05 that had AS03 firmware, the fohdeesha files didnt work but I successfully updated to AS10 using files at this link
Toshiba AS10 for model number(s) PX05SMB320Y, PX05SMB160Y, PX05SMB080Y, PX05SMB040Y, PX05SVB384Y, PX05SVB192Y, PX05SVB096Y, PX05SVB048Y, PX05SRB384Y, PX05SRB192Y, PX05SRB096Y and PX05SRB048Y. | Driver Details | Dell US
firmware support for PX05SMB320Y, PX05SMB160Y, PX05SMB080Y, PX05SMB040Y, PX05SVB384Y, PX05SVB192Y, PX05SVB096Y, PX05SVB048Y, PX05SRB384Y, PX05SRB192Y, PX05SRB096Y and PX05SRB048Y
Dell site shows AS10 Release date 24 Oct 2019
I reviewed the release notes and there's no mention of any bug fix related to this thread. Does anyone know what firmware versions or release dates we should be targeting in order to resolve the " power on hours bug "? I doubt these firmware updates fix the bug since post in the other thread that bricked devices flashed to AS10 did not work anyway. https://forums.servethehome.com/index.php?threads/toshiba-px05srb-ssd-failures.43665/post-449361

Other similar looking dell PX05 with different AV02 firmware and the fohdeesha files don't work and I cannot find any dell website pages or files to update the AV02 firmware. The above dell link to AS10 firmware update does not work on these AV02 firmware drives, and searching I cannot find any other dell updates for AV** firmwares lol.

Fyi quick search I also found PowerEdge: PM2, PM2+, PM2R SSDs drives locking after 70000 Power On Hours | Dell Botswana
which identifies PX03 are affected, not only PX02 and PX05:
"

PM2R N9PTK PX03SNF080 800GB
PM2R 0MXR2 PX03SNB160 1.6TB

"
and also identifies:
"
Resolution

Fixed in firmware versions
PM2, Drive Firmware A3B4
PM2+, Drive Firmware A4B4
PM2R, Drive Firmware A5B4
Firmware update Web posted 24th August 2023.
"

Does anyone know what firmware versions or firmware release dates are required to resolve this bug?

So I came across a bunch of Dell PX05SMB160Y 1.6TB guys and also cannot figure out if A) they need to be updated or B) how to get the firmware. I even put them in an R740 which they came from, loaded up Lifecycle Controller and they don't report as needing a firmware update. When did try to flash the BIN files that are around here it fails.

=== START OF INFORMATION SECTION
=== Vendor: TOSHIBA
Product: PX05SMB160Y
Revision: AS0E

Percentage used endurance indicator: 1%
Current Drive Temperature: 25 C
Drive Trip Temperature: 64 C
Accumulated power on time, hours:minutes 19071:00
Manufactured in week 36 of year 2018
Elements in grown defect list: 0

I downloaded teh AS10 BIN file above and it did see each disk out of version and updated them... now to figure out if that fixes the 70k hour thing

BackupProphet · Dec 6, 2025

Good lord, each model has like 20 different firmware paths. How is this sustainable? They are making firmware updates hell on earth for the secondary market.

acesea · Dec 6, 2025

BackupProphet said:
I downloaded teh AS10 BIN file above and it did see each disk out of version and updated them... now to figure out if that fixes the 70k hour thing

reputable source says no AS10 does not fix bug, see: https://forums.servethehome.com/index.php?threads/toshiba-px05srb-ssd-failures.43665/post-449361

Charles S. said:
... been running these 960GB PX05SRB096Y drives with no issues for years all of a sudden have 10-20 drives across a few node vSAN cluster where they show 0 bytes. This just happened almost overnight with firmware version AS0B. Upgraded to AS10 which is the last release of the firmware from 2022 but still showing 0 bytes...

5mall5nail5 said:
I even put them in an R740 which they came from, loaded up Lifecycle Controller and they don't report as needing a firmware update.

Forgot to mention that was the first thing I did too with all the dell labelled toshiba kioxia crap we have and dell lifecycle controller did not find or report any firmware updates for the drives. The dell labelled drives, in a dell server, dell lifecycle controller can't find any dell firmware updates lol. Manually searching dell.com website provides no search results because dell.com does not accept dpn dell part number of devices ie ssd disk drives as query-able. Need to manually use search engines and hope some related dell.com sites are indexed.

Humorous dell very easily provides frequent seamless dell lifecycle controller firmware updates for ie Liteon and Delta power supplies lol. Yet garbage storage devices from Kioxia toshiba have manufactured termination dates for data lol.

fohdeesha doing God's work even for kioxia crapware

BackupProphet said:
Good lord, each model has like 20 different firmware paths. How is this sustainable? They are making firmware updates hell on earth for the secondary market.

everyone do your part, kioxia should have no market.

EasyRhino · Dec 10, 2025

@fohdeesha thanks so much, I was so inspired by the success on two drives, that I dug another two out of the dumpster pile at work.

Now I don't actually need the drives so I'm not sure what I'll do with them. But they're 7mm small so that's nice.

John Hughes · Dec 16, 2025

Well, this was a very interesting post to run across as I was looking for information about buying some new-old SSDs.

I have a few old TOSHIBA SSDs:

TOSHIBA PX05SMB040 0102 400GB
TOSHIBA PX05SMB040Y AS0B 400GB

Luckily they're not yet at 70k hours:

Accumulated power on time, hours:minutes 38347:48

I assume that they will be vulnerable to this bug? Any idea what firmware they need?

I have no idea who originally sold them -- I bought them second hand.

EasyRhino · Dec 17, 2025

John Hughes said:
TOSHIBA PX05SMB040 0102 400GB
TOSHIBA PX05SMB040Y AS0B 400GB

are your drives dell or EMC labeled at all? They match dell's site. I would try the AS10 firmware first.

Toshiba AS10 for model number(s) PX05SMB320Y, PX05SMB160Y, PX05SMB080Y, PX05SMB040Y, PX05SVB384Y, PX05SVB192Y, PX05SVB096Y, PX05SVB048Y, PX05SRB384Y, PX05SRB192Y, PX05SRB096Y and PX05SRB048Y. | Driver Details | Dell US

John Hughes · Dec 18, 2025

EasyRhino said:
are your drives dell or EMC labeled at all? They match dell's site. I would try the AS10 firmware first.

Toshiba AS10 for model number(s) PX05SMB320Y, PX05SMB160Y, PX05SMB080Y, PX05SMB040Y, PX05SVB384Y, PX05SVB192Y, PX05SVB096Y, PX05SVB048Y, PX05SRB384Y, PX05SRB192Y, PX05SRB096Y and PX05SRB048Y. | Driver Details | Dell US

It's going to take me some time to do this as the damned things are in a datacentre and they'll be a bit hard to get to before the new year

Thanks for the info, however earlier posts seem to suggest that AS10 doesn't fix it.

koejul · Dec 19, 2025

Hello everyone and thank you @fohdeesha for your great work!

I have three Toshiba 5SRQ192BCLAR1920 drives, according to seller with about 43k power on hours.
But I am not able to format any of the drives and smartctl does not output any "real" smart data, just general model info etc.
Firmware seems to be the latest (PB4F).

May I ask for your opinion on the issue?
May that be some software/firmware issue or are the drives just cooked?

I have two drives with the following logs:

Code:

# smartctl -a /dev/sg8
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-6.6.78-Unraid] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               TOSHIBA
Product:              5SRQ192BCLAR1920
Revision:             PB4F
Compliance:           SPC-4
LU is resource provisioned, LBPRZ=1
Rotation Rate:        Solid State Device
Form Factor:          2.5 inches
Logical Unit id:      0x58ce38ee2052e995
Serial number:        88E0A0W6TNPE
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Fri Dec 19 19:08:11 2025 Europe
device becoming ready (wait)
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.


# sg_inq /dev/sg8
standard INQUIRY:
  PQual=0  PDT=0  RMB=0  LU_CONG=0  hot_pluggable=0  version=0x06  [SPC-4]
  [AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=1  Resp_data_format=2
  SCCS=0  ACC=0  TPGS=0  3PC=0  Protect=1  [BQue=0]
  EncServ=0  MultiP=1 (VS=0)  [MChngr=0]  [ACKREQQ=0]  Addr16=0
  [RelAdr=0]  WBus16=0  Sync=0  [Linked=0]  [TranDis=0]  CmdQue=1
  [SPI: Clocking=0x1  QAS=0  IUS=0]
    length=96 (0x60)   Peripheral device type: disk
 Vendor identification: TOSHIBA
 Product identification: 5SRQ192BCLAR1920
 Product revision level: PB4F
 Unit serial number: 88E0A0W6TNPE


# sg_inq -p di /dev/sg8
VPD INQUIRY: Device Identification page
  Designation descriptor number 1, descriptor length: 12
    designator_type: NAA,  code_set: Binary
    associated with the Addressed logical unit
      NAA 5, IEEE Company_id: 0x8ce38e
      Vendor Specific Identifier: 0xe2052e995
      [0x58ce38ee2052e995]
  Designation descriptor number 2, descriptor length: 12
    transport: Serial Attached SCSI Protocol (SPL-4)
    designator_type: NAA,  code_set: Binary
    associated with the Target port
      NAA 5, IEEE Company_id: 0x8ce38e
      Vendor Specific Identifier: 0xe2052e996
      [0x58ce38ee2052e996]
  Designation descriptor number 3, descriptor length: 8
    transport: Serial Attached SCSI Protocol (SPL-4)
    designator_type: Relative target port,  code_set: Binary
    associated with the Target port
      Relative target port: 0x1
  Designation descriptor number 4, descriptor length: 12
    transport: Serial Attached SCSI Protocol (SPL-4)
    designator_type: NAA,  code_set: Binary
    associated with the Target device that contains addressed lu
      NAA 5, IEEE Company_id: 0x8ce38e
      Vendor Specific Identifier: 0xe2052e994
      [0x58ce38ee2052e994]
  Designation descriptor number 5, descriptor length: 28
    transport: Serial Attached SCSI Protocol (SPL-4)
    designator_type: SCSI name string,  code_set: UTF-8
    associated with the Target device that contains addressed lu
      SCSI name string:
      naa.58CE38EE2052E994


# sg_format --format --size=512 /dev/sg8
    TOSHIBA   5SRQ192BCLAR1920  PB4F   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: 88E0A0W6TNPE
      LU name: 58ce38ee2052e995
MODE SENSE (10) command: Device not ready
    try '-v' for more information
sg_format failed: Device not ready

And I have one drive with the following logs:

Code:

# smartctl -a /dev/sg8
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-6.6.78-Unraid] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               TOSHIBA
Product:              5SRQ192BCLAR1920
Revision:             PB4F
Compliance:           SPC-4
LU is resource provisioned, LBPRZ=1
Rotation Rate:        Solid State Device
Form Factor:          2.5 inches
Logical Unit id:      0x58ce38ee20534f51
Serial number:        88F0A2AYTNPE
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Fri Dec 19 18:52:18 2025 Europe
device Test Unit Ready  [medium or hardware error (serious)]
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options


# sg_inq /dev/sg8
standard INQUIRY:
  PQual=0  PDT=0  RMB=0  LU_CONG=0  hot_pluggable=0  version=0x06  [SPC-4]
  [AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=1  Resp_data_format=2
  SCCS=0  ACC=0  TPGS=0  3PC=0  Protect=1  [BQue=0]
  EncServ=0  MultiP=1 (VS=0)  [MChngr=0]  [ACKREQQ=0]  Addr16=0
  [RelAdr=0]  WBus16=0  Sync=0  [Linked=0]  [TranDis=0]  CmdQue=1
  [SPI: Clocking=0x1  QAS=0  IUS=0]
    length=96 (0x60)   Peripheral device type: disk
 Vendor identification: TOSHIBA
 Product identification: 5SRQ192BCLAR1920
 Product revision level: PB4F
 Unit serial number: 88F0A2AYTNPE


 # sg_inq -p di /dev/sg8
VPD INQUIRY: Device Identification page
  Designation descriptor number 1, descriptor length: 12
    designator_type: NAA,  code_set: Binary
    associated with the Addressed logical unit
      NAA 5, IEEE Company_id: 0x8ce38e
      Vendor Specific Identifier: 0xe20534f51
      [0x58ce38ee20534f51]
  Designation descriptor number 2, descriptor length: 12
    transport: Serial Attached SCSI Protocol (SPL-4)
    designator_type: NAA,  code_set: Binary
    associated with the Target port
      NAA 5, IEEE Company_id: 0x8ce38e
      Vendor Specific Identifier: 0xe20534f52
      [0x58ce38ee20534f52]
  Designation descriptor number 3, descriptor length: 8
    transport: Serial Attached SCSI Protocol (SPL-4)
    designator_type: Relative target port,  code_set: Binary
    associated with the Target port
      Relative target port: 0x1
  Designation descriptor number 4, descriptor length: 12
    transport: Serial Attached SCSI Protocol (SPL-4)
    designator_type: NAA,  code_set: Binary
    associated with the Target device that contains addressed lu
      NAA 5, IEEE Company_id: 0x8ce38e
      Vendor Specific Identifier: 0xe20534f50
      [0x58ce38ee20534f50]
  Designation descriptor number 5, descriptor length: 28
    transport: Serial Attached SCSI Protocol (SPL-4)
    designator_type: SCSI name string,  code_set: UTF-8
    associated with the Target device that contains addressed lu
      SCSI name string:
      naa.58CE38EE20534F50


# sg_format --format --size=512 /dev/sg8
    TOSHIBA   5SRQ192BCLAR1920  PB4F   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: 88F0A2AYTNPE
      LU name: 58ce38ee20534f51
MODE SENSE (10) command: Device not ready
    try '-v' for more information
sg_format failed: Device not ready

The only noticeable difference is the line "device Test Unit Ready [medium or hardware error (serious)]" / "device becoming ready (wait)"

If there is any more information needed, I will be happy to provide it.

Guide: Reviving Toshiba / Kioxia PX02 & PX05 drives

Well-Known Member

New Member

New Member

Kaini Industries

New Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

New Member

Well-Known Member

Active Member

Well-Known Member

New Member

Well-Known Member

New Member

Well-Known Member

New Member

New Member