You will finish with a way to inspect a SCSI device's identifying information, save a byte-for-byte backup, and restore it if required. The examples use sg_ident from the installed sg3-utils package, version 1.46-3ubuntu4. The local manpage is labelled sg3_utils 1.43 and dated August 2018, while the installed binary reports 1.23 20180814; the command-line behaviour used here is present in both.
Allow about fifteen minutes for a read-only inspection, or longer if you are making a change and checking the result. You need a SCSI device that supports the REPORT and SET IDENTIFYING INFORMATION commands. Reading may work as an ordinary user, but writing normally needs elevated privileges and a device that permits the operation.
Check the binary and package before you touch a device. These commands are read-only:
$ command -v sg_ident
/usr/bin/sg_ident
$ sg_ident --version
sg_ident: version: 1.23 20180814
$ dpkg-query -W -f='${Package} ${Version}\n' sg3-utils
sg3-utils 1.46-3ubuntu4
Checkpoint: replace /dev/sdX below with the actual SCSI generic or block device for your target. Confirm it with your normal inventory tools before continuing. A wrong path can address a different disk, and this utility can persist data on the device.
Run sg_ident with no action option. It sends REPORT IDENTIFYING INFORMATION for type 0 and prints a hexadecimal view with an ASCII column:
$ sg_ident /dev/sdX
00 31 32 33 34 35 36 37 38 39 30 1234567890
The bytes and text above are an example from the manpage, not a promise about your device. An empty response can mean that no information is set. A SCSI error can instead mean that the device does not support this command, rejects the requested information type, or cannot be accessed with the current permissions.
To request the information as text, use --ascii:
$ sg_ident --ascii /dev/sdX
1234567890
Use this only when the information is text. For arbitrary bytes, use --raw so that no display formatting is mixed into the data.
Information type 127 is reserved for a report of available types and their maximum lengths, if the device supports it:
$ sg_ident --itype=127 /dev/sdX
...device-specific list of supported information types...
The output is device-specific, so treat it as a capability report rather than a fixed format. Types 0 through 126 carry the information itself. Do not use odd-numbered types from 3 through 125, because the manpage reserves them to avoid a clash with SCC-2. Type 127 cannot be used with --set or --clear.
This is the safety checkpoint. Save the raw bytes before a write, and make sure the destination is a new, deliberately named file:
$ umask 077
$ sg_ident --raw --itype=0 /dev/sdX > ./sdX-ident-type0.backup
$ wc -c ./sdX-ident-type0.backup
<device-specific byte count> ./sdX-ident-type0.backup
There is no undo built into sg_ident. The backup is your recovery path. Do not redirect to a file you need to preserve, and do not assume a text editor will retain binary data. If the command fails, stop and inspect the diagnostic on standard error; do not proceed to a clear or set operation.
Writing is persistent: the value is stored in non-volatile device media and can survive a power outage. Stop any workflow that depends on the current identifier, verify the device path again, and take the write step only when you accept that risk.
$ sudo sh -c 'cat ./sdX-ident-type0.backup | sg_ident --set --itype=0 /dev/sdX'
$ printf 'exit status: %s\n' "$?"
exit status: 0
--set reads standard input until EOF. The input must contain between 1 and 512 bytes. The command sets the complete input, not an append or a partial edit. For information types 1 through 126, the manpage says the value should be a null-terminated UTF-8 string, and those types have a maximum of 256 bytes. Type 0 has a documented SPC-4 range of 64 to 512 bytes, although older devices may support less. Follow the capability report and the device documentation.
Checkpoint: read the value back immediately:
$ sudo sg_ident --raw --itype=0 /dev/sdX > ./sdX-ident-type0.after
$ cmp -- ./sdX-ident-type0.backup ./sdX-ident-type0.after
$ printf 'verification status: %s\n' "$?"
verification status: 0
cmp returning zero means the bytes match the backup. If they do not, preserve both files and investigate before attempting another write.
Clearing sends SET IDENTIFYING INFORMATION with a zero-length value:
$ sudo sg_ident --clear --itype=0 /dev/sdX
$ printf 'exit status: %s\n' "$?"
exit status: 0
This is destructive to the stored identifying information. Restore it from the backup by using --set again:
$ sudo sh -c 'cat ./sdX-ident-type0.backup | sg_ident --set --itype=0 /dev/sdX'
Do not use --clear or --set with type 127. If the device rejects a write, keep the backup and the complete error message. A successful exit status is zero; otherwise consult the device error and the sg3_utils(8) diagnostics.
sg_ident does not edit the vendor and product strings returned by standard SCSI INQUIRY. It also does not change the Device Identification VPD page or the media and logical-unit serial features mentioned by the manpage. Use the matching inspection utility when you need those other identifiers. Do not treat this writable value as proof of a manufacturer's serial number or as a stable identity across replacement hardware.
sg_ident version and the exact target device.cmp.