I got a replacement for my Samsung MZVLW256HEHP-000L7 NVMe 256GB M.2 PCI
Express X4 SSD, known also simply as Samsung PM961. It is an OEM part.
After replacing it with the new one, Samsung 980 1TB, I put the old one on
sale. This was my daily driver, so I did not want any meaningful data to be
recoverable from it. So I connected it to the computer with the USB to NVME
M.2 converter (AXAGON EEM2-SG2), which by the way I can now recommend (no
affiliate link, sorry) and started the old, magnetic HDD type of secure
data erase, using
Caution: the following command(s) will IRREVERSIBLY destroy your data. Proceed only when you understand the implications!
shred -vfz /dev/sdX
But stop! The
shred or similar utility like
is not a best way to securely erase SSD!
The thread recommends
blkdiscard -s /dev/sdX
This command on the other hand should not decrease the lifespan of the SSD
so drastically the
shred does, but looks like data are still quite
recoverable after (depending on the threat model). It did not work for me
blkdiscard: /dev/nvme0n1: BLKSECDISCARD ioctl failed: Operation not supported
Looking around the Internet it then suddenly became apparent to me that there are at least a dozen ways to "securely and properly erase an NVME SSD".
Starting with this answer
talking about the way ATA SSD drives can be securely erased quickly just by
changing the encryption password using the
hdparm --user-master u --security-set-pass hunter1 /dev/sdX hdparm --user-master u --security-erase hunter1 /dev/sdX
This failed, but I expected it, as my drive was NVME SSD, not SATA SSD. The output for the record:
Issuing SECURITY_SET_PASS command, password="hunter1", user=user, mode=high SECURITY_SET_PASS: Inappropriate ioctl for device
However, this got me on the track, as I had no idea about this whole
"encryption password" rabbit hole. Searching further led me to another
answer explaining the same
process, but for NVME drives using the
nvme-cli utility. Exactly what I
needed. A quick glance at the options:
sudo pacman install nvme-cli man nvme format man nvme sanitize
This is probably what I needed - securely erase the drive, resetting the
drive's cryptographic password during the process (
nvme list nvme format -s2 /dev/nvme0n1
Running NVME sanitize would probably be even better option as it appears to also clear any caches, not just the data in the namespace, but I would definitely need more time studying both. Also, I could not even run in properly, getting complains about bad sanitize argument. Consider doing your own research.
nvme tool however failed right on the step 1 listing the devices
nvme list. The reason is that the USB to NVME M.2 converter
probably does not implement all the required commands, as hinted in this
So I put the old NVME back into the laptop and booted a live Linux image
from the USB. Now, the NVME connected over native PCIe lanes without any
USB converted in the way, the
nvme list command properly recognized the
drive, outputting detailed information about Node, Generic, SN, Model,
Namespace, Usage, Format and FW Revision of the PM961 drive.
The Debian live did not complain, but the Arch live, probably due to a
newer version of
nvme-cli complained a little bit before outputting the
contents of the
nvme list, but proceeded as well:
nvme0: Identify(0x6), Invalid Field in Command (sct 0x0 / sc 0x2)
nvme format command again failed spectacularly in Debian live:
NVMe status: INVALID_OPCODE: The associated command opcode field in not valid(0x2001)
In Arch live, the error was, as expected, even a little bit more verbose:
nvme0: Format NVM(0x80), Invalid Command Opcode (sct 0x0 / sc 0x1) NVMe status: Invalid Command Opcode: A reserved coded value or an unsupported value in the command opcode field(0x2001)
Ouch. It is noted here and here that it is a known bug for a Samsung PM951 and PM961 and s simple suspend should resolve the issue. I was happy a for a brief moment. Sadly, somehow this has did not work for me, yet again. There was no change in the behavior From here on, the ride was a steep downhill.
Other suggestions in the above two GitHub threads were to use a Lenovo EFI application which is a bootable image that works on ThinkPads (I still rock the trusty T470 at the time of writing) and is meant to erase a cryptographic key on the SSD. I was not able to boot this piece of software by any means, not in UEFI mode, nor in Legacy BIOS mode, nor in any other combination that came to my mind (there is note about it being supported only in UEFI only or UEFI First boot mode).
Another option is to use Lenovo NVME Firmware Utility which is for Windows (but I can dual-boot from mSATA PCIex1 Transcend 430S 512GB internal SSD drive), but following these instructions it appears the updater utility could even be run on Arch or other Linux distribution (again, not tested yet). Trying this on Windows, it correctly identified both Transcend 430S and Samsung PM961 to be present, but it did not offer a Firmware update for either. So no luck here.
As a last resort, I tried the
easier firmware upgrade option,
fwupdmgr which is part of the
package but, as I expected,
it did not pick the Samsung PM961 SSD for an update. It did however updated
my Intel Management Engine and also System Firmware, which I assume was
BIOS, as the next reboot updated the BIOS with a new version containing
breaking changes to EFI (that were mentioned during the install process),
which in turn required me to reinstall GRUB from live Arch. Living on the
This is the end. In the beginning I thought it would be a simple device
formatting and here I am in the middle of the night with the drive that is
still not prepared to be handed to some stranger. Will probably go for the
shred and hope for the best. Wish me luck!