NVME Admin command error: INVALID_OPCODE(2001)

I purchased Parted Magic to erase the drive in a new X1 Carbon 20FB-004QUS, however, although I can run Erase Disk - NVMe Secure Erase option and see the drive (Samsung MZVKV512HAJH-000L1), the erase process ends with "/dev/nvme0n1: Error! Disk is not erased". I then attempted a command line "nvme format /dev/nvme0n1 --ses=1", as well as "nvme format /dev/nvme0n1" (which a Parted Magic support forum admin confirmed is the command they use), but in both cases I get "Admin command error:INVALID_OPCODE(2001)" as the result. The Parted Magic forum admin requested that I contact you directly for assistance. Any feedback on how to correctly secure erase this drive is appreciated.

Thank you.

That doesn't sound right since format is not an optional command to support for any device. It's required. Perhaps the device's status is incorrect, and maybe it doesn't like using the "all namespaces". Do you get the same error from running:

# nvme format /dev/nvme0 -n 1

?

Yes, same error.

Okay, in this case, I recommend forwarding the error to the controller vendor. It sounds like they require something not defined in the specification, or they simply don't support the nvme format admin command.

Closing; this appears to be a device side issue.

I think the work-around is to just not issue format commands. The device doesn’t support it according to the status code. From: fuzzydunlop1899 [mailto:notifications@github.com] Sent: Tuesday, May 2, 2017 8:06 PM To: linux-nvme/nvme-cli <nvme-cli@noreply.github.com> Cc: Busch, Keith <keith.busch@intel.com>; State change <state_change@noreply.github.com> Subject: Re: [linux-nvme/nvme-cli] NVME Admin command error: INVALID_OPCODE(2001) (#84) Hi, I have the exact same problem with the Samsung SM951 256 GB NVMe drive (MZVPV256HDGL-00000) and was also routed here via the Parted Magic forum. Since the SM951 is an unsupported OEM-Product I hope there might be a so workaround by now. Thank you! — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub<#84 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEDXlhtIf_gLHumqcliniPMQ0OmzY27nks5r1-D-gaJpZM4Iak7r>.

Samsung PM961 128G responds with NVME Admin command error:8193 when nvme_format_ns /dev/nvme0n1 is sent on ASrock Taichi Z270 running CentOS 7.3.1611.el7.
Same SSD/same command/same OS issued on ASUS Maximus Gene VII Z97 completes successfully. Please advise possible problem(s) on Z270 system.

That looks like you're using an older version of this tool, so I'm going to assume 8193 is in decimal. That's 2001 in hex, and according to the spec, that's an invalid opcode error. Supporting the format opcode is optional, so it sounds like controller chose not to support it, and that's okay from a specification standpoint.

Thank you for this reply. Using the very latest version of the tool gives this response: [root@cabench11 Desktop]# nvme format /dev/nvme0n1 NVME Admin command error:INVALID_OPCODE(2001) Issuing this command to this SSD on ASUS Z97 with same OS completes successfully. Same behavior with other Samsung SM/PM version SSDs??? Other thoughts? From: Keith Busch [mailto:notifications@github.com] Sent: Thursday, July 06, 2017 2:10 PM To: linux-nvme/nvme-cli <nvme-cli@noreply.github.com> Cc: Errol Heiman (eheiman) [CONT - Type 2] <eheiman@micron.com>; Comment <comment@noreply.github.com> Subject: [EXT] Re: [linux-nvme/nvme-cli] NVME Admin command error: INVALID_OPCODE(2001) (#84) That looks like you're using an older version of this tool, so I'm going to assume 8193 is in decimal. That's 2001 in hex, and according to the spec, that's an invalid opcode error. Supporting the format opcode is optional, so it sounds like controller chose not to support it, and that's okay from a specification standpoint. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#84 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AckiTHUJKpWIsfxX0F1LDb6E38iGEduMks5sLT78gaJpZM4Iak7r>.

If you want to verify if your controller supports the Format NVM command, run nvme id-ctrl /dev/nvme0 | grep oacs. If value does not have bit 1 set, your controller doesn't support the command, and there's nothing wrong with that from an implementation compliance standpoint.

Both Z270 and Z97 systems yield oacs : 0x7. I suspect OP_CODE is modified by Z270 versus Z97. Comments will be appreciated.
Samsung_format_Z270.txt

An oacs of 7 is advertising support for format nvm. If it's not working, you should take this issue to your vendor.

I owned 2 laptops with Samsung PM951 and PM961 SSDs and both had the same issue: oacs shows support but the format command returns INVALID_OPCODE(2001).
For both machines, the fix is to put to laptop to sleep, then resume it. After resume, the Samsung SSD accepts the command.

Your comment is most appreciated. This same remedy also works for a SATA SSD in security frozen state. Based on that observation, I suspect this is a security related issue, present on Z270 but not on Z97. Review of BIOS configurations is in order. From: Christophe Beyls [mailto:notifications@github.com] Sent: Friday, August 04, 2017 3:07 PM To: linux-nvme/nvme-cli <nvme-cli@noreply.github.com> Cc: Errol Heiman (eheiman) [CONT - Type 2] <eheiman@micron.com>; Comment <comment@noreply.github.com> Subject: [EXT] Re: [linux-nvme/nvme-cli] NVME Admin command error: INVALID_OPCODE(2001) (#84) I owned 2 laptops with Samsung PM951 and PM961 SSDs and both had the same issue: oacs shows support but the format command returns INVALID_OPCODE(2001). For both machines, the fix is to put to laptop to sleep, then resume it. After resume, the Samsung SSD accepts the command. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#84 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AckiTGFaGBpPOsximY9B15Z_hsr48ayxks5sU4gMgaJpZM4Iak7r>.

Just confirming that putting the machine to sleep has also resolved this issue for me.

I recently had to revisit this issue on a PC where the suspend workaround didn't work...

Amazing, thank you for writing this up!

Amazing, Thank you.

@aggieNick02

Well for any owners of Dell systems out there, this seem to be the trick for disabling the block on SID authentication on them...

https://www.dell.com/support/kbdoc/en-uk/000126083/pre-boot-authentication-will-not-activate-due-to-sed-block-sid-authentication-enabled

Although at least in my case the XPS 9360 doesn't have this option in its BIOS (and it's on the latest version). But like I said previously, they've at least given us a built in option to do this in the BIOS under the menu/screen... Maintenance | Data Wipe

Great to finally understand what the real issue is though, thanks @aggieNick02

I think we should add this info to our documentation, as it seems a very common thing to happen.

BTW, nvme has a very minimalist SED plugin. Not sure if it supports the steps necessary feature this workaround requires though.

I think we should add this info to our documentation, as it seems a very common thing to happen.

BTW, nvme has a very minimalist SED plugin. Not sure if it supports the steps necessary feature this workaround requires though.

Oh nice, thanks for the info. I'll see if I can test it; it looks like it has the necessary commands, I don't know if it works with drives with Pyrite or Opalite, but regardless having support for this appearing in nvme-cli is encouraging since where to find a sedutil with needed fixes is not super obvious.

I think we should add this info to our documentation, as it seems a very common thing to happen.
BTW, nvme has a very minimalist SED plugin. Not sure if it supports the steps necessary feature this workaround requires though.

Oh nice, thanks for the info. I'll see if I can test it; it looks like it has the necessary commands, I don't know if it works with drives with Pyrite or Opalite, but regardless having support for this appearing in nvme-cli is encouraging since where to find a sedutil with needed fixes is not super obvious.

I grabbed Ubuntu 24.04 LTS and quickly tried with the SN750. Unfortunately, it looks like it does not work with Pyrite drives yet. I get an ioctl IOC_OPAL_DISCOVERY failed error message. It looks like Greg Joyce (who added the nvme-cli sed plugin) added the ioctl call to Linux to get the basic information out, and my best guess is that would need to be tweaked before it could work on Pyrite and possibly Opalite.

I've no idea how common Pyrite or Opalite drives are, it just is what the problematic SN750 I was dealing with implemented.

@gjoyce-ibm

@gjoyce-ibm Maybe Greg has some insights here. I really have no clue when it comes to SED :)

When I started looking at SED, there were two viable CLIs, sedcli and sedutil. Both projects however went dormant and had no support or new development.

Given that state I decided that nvme-cli was the best course. But given no real requirements I chose to implement only a base set of OPALv2 functionality. This subset allows for many use cases but certainly not all. The implementation relies entirely on the ioctl's provided by the kernel block SED Opal driver (block/sed_opal.c).

I'm not sure how Pyrite support works but it may be that sedcli/sedutil use the NVMe pass-through mechanism to access the drives directly without using the block SED Opal driver.

I'm a little surprised that ioctl IOC_OPAL_DISCOVERY just failed. Is it possible that your kernel doesn't have that patch?

I'm a little surprised that ioctl IOC_OPAL_DISCOVERY just failed. Is it possible that your kernel doesn't have that patch?

I was using Ubuntu 24.04LTS. Do you know offhand which kernel version was the first to have the patch? I can try to dig more later to find out if needed.

This is the commit to the fork of sedutil that added Pyrite support in case its helpful:
ChubbyAnt/sedutil@5ad84d8

I'll be unable for the next week or two to look at the tech details of this, but am happy to look more and help after that. Thanks for sharing this info and all of the work on adding support for this to nvme-cli. :)

It went into kernel 6.7.

commit 9fb10726ecc5145550180aec4fd0adf0a7b1d634
Author: Greg Joyce gjoyce@linux.vnet.ibm.com
Date: Fri Jul 21 16:15:32 2023 -0500

block: sed-opal: Implement IOC_OPAL_DISCOVERY

Add IOC_OPAL_DISCOVERY ioctl to return raw discovery data to a SED Opal
application. This allows the application to display drive capabilities
and state.

Signed-off-by: Greg Joyce <gjoyce@linux.vnet.ibm.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jonathan Derrick <jonathan.derrick@linux.dev>
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://lore.kernel.org/r/20230721211534.3437070-2-gjoyce@linux.vnet.ibm.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Thanks for the info. Ubuntu 24.04LTS is on the 6.8 kernel, so it should have your patch. When I have time in a couple weeks I'll try to dig a bit and get some more info about why it isn't working on the Pyrite device I tried.

One other possibility... you need the following kernel configuration:

CONFIG_BLK_SED_OPAL=y

I finally got back and had some time to check this. I'm running Ubuntu 24.04LTS server live (from the USB without installing). Entering the shell from the installer, I do

root@ubuntu-server:/# cat /boot/config-6.8.0-31-generic | grep BLK_SED
CONFIG_BLK_SED_OPAL=y

so it seems like everything should be in place, at least for proper Opal.

So I encountered some Opal 2.0 SSDs recently (Crucial P5 1TB and 2TB) that presented with the same issue of being unable to format due to the Block SID feature. Using sedutil-cli to do initial setup remedied that issue but introduced a new one.

The output running --initialSetup is slightly different with an Opal drive:

~$ sudo ./sedutil-cli --initialSetup my_secret_password /dev/nvme0
SID password changed
takeOwnership complete
Locking SP Activate Complete
LockingRange0 disabled
LockingRange0 set to RW
MBRDone set on
MBREnable set on
Initial setup of TPer complete on /dev/nvme0

The MBRDone and MBREnable lines are new. On cold boot, MBRDone is set to off and the "shadow MBR" is enabled because MBREnable is set to on. This feature makes a different portion of the SSD act as the first 128MB of the drive, and this portion is readonly. This causes some simple fio commands to fail:

~$ fio --name=foo --iodepth=1 --rw=write --bs=128k --size=10M --filename=/dev/nvme0n1 --direct=1
foo: (g=0): rw=write, bs=(R) 128KiB-128KiB, (W) 128KiB-128KiB, (T) 128KiB-128KiB, ioengine=psync, iodepth=1
fio-3.36
Starting 1 process
fio: io_u error on file /dev/nvme0n1: No data available: write offset=0, buflen=131072
fio: pid=1474, err=61/file:io_u.c:1896, func=io_u error, error=No data available

Oddly, removing --direct=1 allows the fio run to succeed, which I'm at a loss to explain. If anyone has a guess as to how that is possible, I'm very interested.

Anyways, the "fix" if you do not care about using the shadow MBR feature is to disable it permanently by running:

~$ sudo ./sedutil-cli --setMBREnable off my_secret_password /dev/nvme0

I'll update my original post shortly to reflect this.

@gjoyce-ibm

One other possibility... you need the following kernel configuration:

CONFIG_BLK_SED_OPAL=y

Update for @gjoyce-ibm and others on the nvme sed plugin and Opal/Pyrite:

After running into some Opal 2.0 devices recently, I booted Ubuntu 24.04LTS with one present, and was able to successfully run
nvme sed discover /dev/nvme0n1 . Then to be certain, I powered off, switched to a Pyrite device, and booted up, and the same command returned the ioctl IOC_OPAL_DISCOVERY failed message.

So it appears that full Opal 2.0 devices work with the nvme sed plugin, but Pyrite devices do not.

Navigation Menu

Repository navigation

NVME Admin command error: INVALID_OPCODE(2001) #84

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

NVME Admin command error: INVALID_OPCODE(2001) #84

Description

Activity

keithbusch commented on May 9, 2016

mdp2000 commented on May 9, 2016

keithbusch commented on May 9, 2016

keithbusch commented on May 10, 2016

keithbusch commented on May 3, 2017

eheiman commented on Jul 6, 2017

keithbusch commented on Jul 6, 2017

eheiman commented on Jul 6, 2017

keithbusch commented on Jul 6, 2017

eheiman commented on Jul 6, 2017

keithbusch commented on Jul 6, 2017

cbeyls commented on Aug 4, 2017

eheiman commented on Aug 7, 2017

fallspectrum commented on Aug 9, 2017

16 remaining items

keithbusch commented on Jun 21, 2024

HaroPanosyan commented on Jun 21, 2024

Lantizia commented on Jun 22, 2024

igaw commented on Jun 24, 2024

aggieNick02 commented on Jun 24, 2024

aggieNick02 commented on Jun 24, 2024

igaw commented on Jun 25, 2024

gjoyce-ibm commented on Jun 26, 2024

aggieNick02 commented on Jun 28, 2024

gjoyce-ibm commented on Jun 28, 2024

aggieNick02 commented on Jul 1, 2024

gjoyce-ibm commented on Jul 1, 2024

aggieNick02 commented on Jul 15, 2024

aggieNick02 commented on Jul 16, 2024

aggieNick02 commented on Jul 16, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions