Inspect SCSI Identity and VPD Data Safely with sg_inq

You will use sg_inq to identify a SCSI device and inspect its Vital Product Data (VPD) pages. It can also decode a saved INQUIRY response without touching hardware. The examples match sg3-utils 1.46-3ubuntu4, whose installed sg_inq reports version 2.10 dated 28 March 2021. Allow about 15 minutes, plus time to identify the correct storage path.

You need the sg3-utils package and a readable SCSI, block, ATA or supported NVMe device. Most commands only read device data and do not need elevated privileges, but a device node may still require membership of a storage group or a root shell. Do not guess a path such as /dev/sda on a production host.

1. Check the installed command

Confirm which executable will run and record its version before comparing output with another system:

$ command -v sg_inq
/usr/bin/sg_inq
$ sg_inq --version
Version string: 2.10 20210328
sg3-utils 1.46-3ubuntu4

The command has a preferred long-option interface and an older interface retained for compatibility. Use the long names in new scripts. The device argument is mandatory unless you use --inhex to decode a saved response.

2. Run a standard INQUIRY

After confirming the path, ask for the normal INQUIRY response. Replace the example with the device you have positively identified:

$ sg_inq /dev/sg3
standard INQUIRY:
  PQual=0  PDT=0  RMB=0  LU_CONG=0  hot_pluggable=0  version=0x06  [SPC-4]
  ...
    length=36 (0x24)   Peripheral device type: disk
 Vendor identification: EXAMPLE
 Product identification: EXAMPLE DISK
 Product revision level: 1.0

Your vendor, product and revision will differ. The command opens the device read-only, and a successful exit status is zero. The default request starts at 36 bytes. If the response says that more data is available, sg_inq may issue a second INQUIRY to obtain it and may fetch the serial-number VPD page to improve the displayed result.

Verify the status immediately if a script will depend on it:

$ sg_inq --only /dev/sg3 > /tmp/sg_inq-output.txt
$ printf 'exit status: %s\n' "$?"
exit status: 0

--only prevents the extra serial-number request for a standard INQUIRY. It is a useful first probe when a device produces nuisance errors for optional VPD pages. Redirecting decoded text to a temporary file is safe; choose a controlled destination if the output may contain identifying information.

3. Query supported VPD pages

VPD is supplementary information selected by page. Start with page zero, which lists pages the device says it supports:

$ sg_inq --vpd /dev/sg3
VPD INQUIRY, page code=0x00:
  Supported VPD pages:
    0x00  Supported VPD Pages
    0x80  Unit serial number
    0x83  Device identification

The exact list depends on the device. The equivalent explicit form is sg_inq --vpd --page=0 /dev/sg3. To decode the mandatory Device Identification page when it is listed, use:

$ sg_inq --id /dev/sg3
Device Identification VPD page:
  ...

For a page number not covered by a dedicated option, use --vpd --page=PG, where PG is a page number or the abbreviation shown by sg_inq --help. The normal sanity check reads page zero first and refuses an unlisted page. Warning: --force bypasses that check and the manual warns that the preliminary query is known to crash some USB devices. Use it only when you understand the device risk.

4. Keep a reproducible hex response

Use --hex when you need bytes for an incident record or later decoding. The option writes the response to standard output, so redirect it to a new file:

$ sg_inq --only --hex /dev/sg3 > inquiry.hex
$ test -s inquiry.hex && echo 'saved a non-empty response'
saved a non-empty response

For a file that can be read back by --inhex, use four -H options as documented:

$ sg_inq --only -HHHH /dev/sg3 > inquiry-replay.hex
$ sg_inq --inhex=inquiry-replay.hex --only
standard INQUIRY:
  ...

The replay file is ASCII hexadecimal, not a device image. --inhex accepts whitespace- or comma-separated byte values and ignores text from a hash mark to the end of a line. If you use --raw with --inhex, the input is treated as binary instead.

5. Protect fragile devices

Some weak SCSI implementations can lock up when sent an unexpected command or response length. On hardware with that history, request only the traditional 36-byte response:

$ sg_inq --only --len=36 /dev/sg3

--len=36 causes one INQUIRY and prevents the longer follow-up. It also means that sg_inq will not fetch the serial number through the additional VPD request. The device is still being queried, so this is a caution for fragile hardware, not a guarantee that every device will respond.

Do not use --raw in an ordinary terminal. It sends binary response data to standard output and can make the terminal unreadable. Pipe it to a file or another program instead:

$ sg_inq --only --raw --len=36 /dev/sg3 > inquiry.bin
$ wc -c inquiry.bin
36 inquiry.bin

The byte count can be lower when the host adapter reports a residual count. Keep the original file until you have verified any later analysis.

6. Account for ATA and NVMe paths

On Linux, a failed SCSI INQUIRY can make sg_inq try ATA IDENTIFY handling. To explicitly assume an ATA or ATAPI device, use --ata; this skips SCSI INQUIRY and sends the applicable ATA IDENTIFY command:

$ sg_inq --ata /dev/sr0
... device identification output ...

The installed manual says that sg_inq does not fully decode the ATA IDENTIFY response. If you need that format, its documented --ata -HHH combination is intended for piping to hdparm --Istdin. That is a separate tool and should be checked before using it in an automated report.

Supported NVMe devices are handled differently: the utility may issue NVMe Identify commands rather than SCSI INQUIRY. Add --long for more decoded controller detail or --only to limit the operation to the controller. If the NVMe device has a SCSI Translation Layer and you specifically need SCSI VPD data, the manual directs you to sg_vpd.

7. Recover from common failures

A non-zero status means the operation did not complete successfully. First check the path and permissions without changing anything:

$ ls -l /dev/sg3
$ test -r /dev/sg3 && echo readable
$ sg_inq --only /dev/sg3
$ printf 'exit status: %s\n' "$?"

If the device is busy, disappearing, or returning transport errors, stop repeating the probe. Confirm its identity through your storage inventory and check the relevant kernel or multipath logs. Ask an administrator for access rather than using sudo blindly. Elevated privileges may solve a device-node permission problem, but they cannot repair a failed transport and can make an unsafe target easier to select.

If a VPD page is rejected as unsupported, inspect page zero again. Do not add --force just to silence the error. If a saved response cannot be decoded, confirm whether it is ASCII hex or binary and pair it with the correct --page value when the page cannot be inferred.