Inspect MMC Drive Features with sg_get_config

Point sg_get_config at a CD, DVD or Blu-ray drive and it dumps every MMC profile and feature descriptor the drive admits to. This walks through querying that response, then narrowing it down to just what you need. Allow about ten minutes. You need sg3-utils, a device node for the drive, and permission to open it. The examples use the installed Ubuntu package sg3-utils 1.46-3ubuntu4; the binary reports sg_get_config: version: 0.49 20180626, so output details can differ on another release.

1. Check the installed interface

Start with read-only checks. They need no elevated privileges and do not touch a drive:

$ command -v sg_get_config
/usr/bin/sg_get_config
$ dpkg-query -W -f='${Package} ${Version}\n' sg3-utils
sg3-utils 1.46-3ubuntu4
$ sg_get_config --version
sg_get_config: version: 0.49 20180626

The command sends SCSI GET CONFIGURATION through the MMC command set. In practice the target is usually an optical drive attached through SCSI, ATAPI, USB or IEEE 1394 transport: the word SCSI describes the command interface here, not necessarily the cable or physical bus.

Checkpoint: if the command is missing, stop and install sg3-utils through your normal package-management process. Do not copy a binary in from an unrelated host.

2. Identify the drive device

Use the device path your system has assigned to the drive. Common names include /dev/sr0, /dev/sg0 and, on older systems, /dev/scd0. Look for candidates without changing anything:

$ ls -l /dev/sr* /dev/sg* 2>/dev/null
$ udevadm info --query=property --name=/dev/sr0 2>/dev/null | sed -n '1,12p'

Replace /dev/sr0 in the second command with a path that exists on your machine. Do not guess between several drives: if you have more than one, use udevadm, desktop hardware information or the drive label to establish which device you actually mean.

Access to a device node can be restricted to its owning group. Try the query as your normal user first. If it fails on a permission error, check the node's group and your own group membership before reaching for elevation:

$ id
$ ls -l /dev/sr0
$ sg_get_config --brief /dev/sr0

Running the final command with sudo can be appropriate on a machine whose device policy requires it, but it fixes neither a wrong device path nor an unsupported drive. Keep the elevated form visible when you write the procedure down:

$ sudo sg_get_config --brief /dev/sr0

3. Get a compact feature list

A full response can run long, since modern writers advertise a lot of features. Use --brief to show feature names without decoding their parameter data:

$ sg_get_config --brief /dev/sr0
Feature code: 0x0000
  Profile list
Feature code: 0x0001
  Core
Feature code: 0x0003
  Removable media

Your feature codes and names depend on the drive and its media: this sample is only the shape of a successful decoded response, not a promise about your hardware. The installed command also offers a device-independent catalogue:

$ sg_get_config --list --brief
Known features:
  Profile list [0x0]
  Core [0x1]
  Removable media [0x3]
  CD read [0x1e]
  DVD read [0x1f]

--list ignores the device name entirely and reports what this utility knows, including feature codes. It does not tell you what your drive supports. Use the device query for hardware facts.

4. Show only current features

To focus on features relevant to the media actually in the drive, use --current, an alias for --rt=1:

$ sg_get_config --current /dev/sr0
$ printf 'exit status: %s\n' "$?"
exit status: 0

An exit status of zero means the command completed. It does not mean a disc is present, that it is writable, or that every advertised operation will actually succeed. Read the decoded profiles and feature parameters alongside the drive's documentation and the media you inserted.

The default is --rt=0, asking for all features whether current or not, which is why an unqualified command can produce a wall of output. --rt=1 still returns current features at or after the selected starting code.

5. Inspect one feature by code

Use --rt=2 with --starting=FC when a single feature is the whole point of the check. Feature codes run from 0 to 0xffff; hexadecimal values can use a 0x prefix:

$ sg_get_config --rt=2 --starting=0x0001 /dev/sr0
Feature code: 0x0001
  Core

The starting code is not a profile name and does not select a disc type: it is the numeric feature code in the GET CONFIGURATION command. With --rt=2, the response covers the feature whose code equals that value, if the device reports it. The manual marks --rt=3 reserved, so keep it out of scripts.

Need names plus the feature data in hexadecimal? Use --inner-hex. Need the whole response undecoded for protocol-level digging? Use --hex:

$ sg_get_config --inner-hex --rt=2 --starting=0x0001 /dev/sr0
$ sg_get_config --hex --rt=2 --starting=0x0001 /dev/sr0

6. Keep raw output under control

--raw writes the binary response to standard output. Redirect it to a deliberately named file, or pipe it to a program expecting binary input. Never let it scroll through a terminal:

$ sg_get_config --raw --current /dev/sr0 > get-config.bin
$ test -s get-config.bin && echo 'binary response saved'
binary response saved

This just creates a local file; the drive is unaffected. Treat the file as diagnostic data and clear it out through your normal retention process once it is no longer needed. Omit --raw for readable output instead. Note the option's short form is uppercase -R, not the lowercase -r used for --rt.

7. Diagnose a failed query

Older CD players may not implement GET CONFIGURATION at all. A failure can also mean the path is not an MMC device, the drive is unavailable, or the transport rejected the command outright. Increase diagnostics with --verbose, then check the device independently:

$ sg_get_config --verbose /dev/sr0
$ sg_inq /dev/sr0
$ printf 'exit status: %s\n' "$?"

Do not treat sg_inq output as proof that GET CONFIGURATION is supported: it only shows the path responds to a different SCSI command. On an older drive without GET CONFIGURATION, the manpage points to the older capabilities mode page and tools such as sg_modes or sdparm, which is a different query, not a silent workaround.

If the normal query works but a read-only open fails, that matches documented Linux behaviour: the sg driver needs read-write access for this command by default. --readonly changes the open mode and may be required by another access method, but it can also make a Linux sg query fail outright. It does not make a device safer to query, and it grants no permissions it did not already have.

Nothing here formats, writes or ejects media. Do not bolt on an option from another sg3_utils program, and never feed a raw response into a state-changing tool without first understanding its format.

Done means