Reflashing HGST He10 pulled from VSP G200

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
L

ldperron

New Member
Nov 12, 2018
3
0
1
Hi Forum! I'm trying to recycle a bunch of 10TB HGST SAS drives ( HUH721010AL5204 ) pulled out from a decommissioned VSP SAN array. After reformating them to 512 bytes-per-sector, I still can't use them properly (some sectors reports Medium Error while formatting in XFS... but sectors numbers are always the same between the drives).
Current drive model is shown as DKR2H-H10RSS. I found the appropriate HGST firmware files for this model, but it's not accepted by sg_write_buffer:

root@debian:/home/user# sg_write_buffer -v -m 5 --in LHGNC9U0.bin /dev/sg0
tried to read 8388608 bytes from LHGNC9U0.bin, got 2326528 bytes
will write 2326528 bytes
sending single write buffer, mode=0x5, mpsec=0, id=0, offset=0, len=2326528
Write buffer cdb: [3b 05 00 00 00 00 23 80 00 00]
Write buffer:
Descriptor format, current; Sense key: Illegal Request
Additional sense: Parameter value invalid
Descriptor type: Information: Valid=0 (-> vendor specific) 0x0000000000000000
Descriptor type: Command specific: 0x0000000000000000
Descriptor type: Sense key specific: Field pointer:
Error in Data parameters: byte 0
Descriptor type: Field replaceable unit code: 0x0
Descriptor type: Block commands: Incorrect Length Indicator (ILI) clear
Descriptor type: Vendor specific [0x80]
f1 30
DeWrite buffer failed: Illegal request, type: sense key, apart from Invalid opcode


Anyone has an idea to unlock the firmware so I can flash these as HGST? I have 60 of them!
 
U

UhClem

just another Bozo on the bus
Jun 26, 2012
535
331
63
NH, USA
ldperron said:
Hi Forum! I'm trying to recycle a bunch of 10TB HGST SAS drives ( HUH721010AL5204 ) pulled out from a decommissioned VSP SAN array.

After reformating them to 512 bytes-per-sector, I still can't use them properly ...

Anyone has an idea to unlock the firmware so I can flash these as HGST? I have 60 of them!
Click to expand...
Ideas, and theories etc, are a dime-a-dozen;
But SOLUTIONS ... ahhh, there's the rub.

Here [Link] IS the solution.
 
J

jabuzzard

Member
Mar 22, 2021
99
48
18
Hum, just got access to several hundred of these drives, and unlike the 4TB drives from a previous system, I have not needed to flash the firmware to get around the SCSI WRITE AND VERIFY issue on VSP drives. All I have needed to do is reformat them down to a standard sector size.

However, at this point, I will note these drives have 4k sector size (4160 when taken out of the VSP), so maybe formatting them to 512 bytes is the cause of your problems and reformatting them to 4096 bytes and they will work?
 
J

jabuzzard

Member
Mar 22, 2021
99
48
18
Ok, what I said isn't entirely accurate: the moment you power-cycle the drives, they go back to accepting only SCSI_WRITE_AND_VERIFY commands :(

However, I do have a solution to make drives pulled from a Hitachi VSP system permanently accept standard SCSI_WRITE commands. It does not involve bypassing checks and flashing generic or vendor firmware. All you need is sg3_utils installed.

I have verified it works on 4TB Seagate drives model number ST4000NM0025, 10TB Seagate drives model numbers ST1000NM002G and ST1000NM013G, 10TB Western Digital drives model number HUH721010AL5204, 900GB/10k Seagate drives model number ST900MM0168, and 900GB/10k Hitachi drives model number HUC1090CSS600

I have also verified it works on Seagate drives with model numbers ST4000NM0023. However, these drives, along with model numbers ST9900805SS and ST900MM0006, can be flashed with generic Seagate firmware, which is probably a better idea. I happened to have a single ST4000NM0023 drive that I missed flashing with generic firmware, which was super helpful in working this out.

Basically, you need to set a bit in an undocumented mode page for the drives. This ties in with comments I have seen on the internet that said not being able to write to the drives was indicative of the drives not being properly "exported" from the system.

Right now, it is a very manual process and easy to mess up. However, since I have over 800 drives to process, I'm working on automating the process and will post a link to the code when it is ready.
 
  • Like
Reactions: itronin
C

Clusterzx

New Member
Sep 14, 2026
3
0
1
jabuzzard said:
Ok, what I said isn't entirely accurate: the moment you power-cycle the drives, they go back to accepting only SCSI_WRITE_AND_VERIFY commands :(

However, I do have a solution to make drives pulled from a Hitachi VSP system permanently accept standard SCSI_WRITE commands. It does not involve bypassing checks and flashing generic or vendor firmware. All you need is sg3_utils installed.

I have verified it works on 4TB Seagate drives model number ST4000NM0025, 10TB Seagate drives model numbers ST1000NM002G and ST1000NM013G, 10TB Western Digital drives model number HUH721010AL5204, 900GB/10k Seagate drives model number ST900MM0168, and 900GB/10k Hitachi drives model number HUC1090CSS600

I have also verified it works on Seagate drives with model numbers ST4000NM0023. However, these drives, along with model numbers ST9900805SS and ST900MM0006, can be flashed with generic Seagate firmware, which is probably a better idea. I happened to have a single ST4000NM0023 drive that I missed flashing with generic firmware, which was super helpful in working this out.

Basically, you need to set a bit in an undocumented mode page for the drives. This ties in with comments I have seen on the internet that said not being able to write to the drives was indicative of the drives not being properly "exported" from the system.

Right now, it is a very manual process and easy to mess up. However, since I have over 800 drives to process, I'm working on automating the process and will post a link to the code when it is ready.
Click to expand...
I am stuck at something similar, mine were also pulled from a VSP system as it seems. But these disk do not get "ready", left with " Device not ready ". They only accept INQUIRY, VPD, REPORT LUNS, REQUEST SENSE. They always do a power cycle every few seconds. And there are hundreds of these disk with the same issue.

HGST HUH721212AL5204 HA22

Do you have any suggestions?
 
J

jabuzzard

Member
Mar 22, 2021
99
48
18
Clusterzx said:
I am stuck at something similar, mine were also pulled from a VSP system as it seems. But these disk do not get "ready", left with " Device not ready ". They only accept INQUIRY, VPD, REPORT LUNS, REQUEST SENSE. They always do a power cycle every few seconds. And there are hundreds of these disk with the same issue.

HGST HUH721212AL5204 HA22

Do you have any suggestions?
Click to expand...
If your drives are power cycling every few seconds there is something VERY wrong with either the drives or your setup.

Attempting to use anything other than a vanilla Linux install (so no NAS distribution, Windows etc.), any sort of RAID controller and/or multipathing is a recipe for trouble and you are on your own. The use of a SAS expander aka a external JBOD is however not an issue in my experience. I ONLY have experience of using LSI cards, anything else and again you are on your own.

The expansion enclosures from the VSP are also "funny" in that they don't spin up drives when a machine boots and it will hang. I don't have a solution for that so you will need to remove the drives and put them in something else.

Your first step is to reformat them from 520/4160 block size down to 512/4096 respectively. This will take hours for example a ST4000NM0023 drive takes about 18 hours, and a HUH721010AL5204 drive takes around 12 hours. You can do a whole JBOD simultaneously by running them all individually in a screen. There is a whole thread about reformatting drives to more standard block sizes. I use a shell script that launches a screen for every drive on the system it finds with a 520 or 4160 block size and launches sg_format in a screen for each one. It however is not multipath proof and would likely cause grief if the drives were available via multipathing.

In due course I will post links to a script to make them accept SCSI_WRITE commands but it will be a few weeks as I am going away on holiday shortly.
 
J

jabuzzard

Member
Mar 22, 2021
99
48
18
  • Like
Reactions: Stephan
You must log in or register to reply here.
Top Bottom