Cannot detect the nvme ssd after encryption
sw1520 opened this issue · 7 comments
In ubuntu system command to an ssd that is not a system. run the following command
sedutil-cli --initialsetup PASSWORD /dev/nvme1
sedutil-cli --enablelockingrange 0 PASSWORD /dev/nvme1
sedutil-cli --setlockingrange 0 LK Admin1 PASSWORD /dev/nvme1
reboot
The ssd cannot be found after the system restarts
The same to Windows
Has that happened to anyone? Thank you
what is the output of sedutil-cli --scan after reboot? Please execute the command sedutil-cli --quey /dev/nvme1 and give the message.
After reboot
execute the command 'ls /dev/nvme1' output:cannot access '/dev/nvme1':No such file or directory
execute the command 'sedutil-cli --quey /dev/nvme1'
output: Invalid or unsupported disk /dev/nvme1
This ssd seems to be completely locked and Windows or linux can not detect this ssd
As per my understanding, nvme1 is the controller and nvme1"n1" is a namespace. Even if the drive is completely locked, it will still be visible in OS and we can do Unlock operation from the OS. Does all the nvme modules are loaded in the server?
Thanks
The problem of not detecting the ssd was solved
An new ssd can be unlocked but cannot be detect the partitions and mounted
sedutil-cli --setlockingrange 0 RW Admin1 123456 /dev/nvme0
ls /dev/nvme*
/dev/nvme0 /dev/name0n1
Couldn't find the nvme0n1p1
I’m experiencing the same issue on an SSD I used for testing.
sedutil-cli --initialsetup "$password" /dev/nvme1works.- After a cold reboot, reading the drive yields zeroes.
sedutil-cli --disablelockingrange 0 "$password" /dev/nvme1andsedutil-cli --setmbrenable off "$password" /dev/nvme1returns the SSD to a state where reads returned non-zero bytes.- After a warm reboot, I could access the contents of the drive.
The problem started when I called initialsetup on the SSD again. Subsequently:
sedutil-cli --enablelockingrange 0 "$password" /dev/nvme1sedutil-cli --setlockingrange 0 lk "$password" /dev/nvme1sedutil-cli --setmbrdone off "$password" /dev/nvme1
After a cold reboot, I did not see the SSD listed in the BIOS and sedutil-cli --scan did not detect it either and that was the last time I was able to get the system to start with the SSD attached. All subsequent boots result in infinite boot loop; I’m not even able to get into the BIOS.
EDIT: Putting it in another system caused a password prompt to pop up pre-boot. Apparently, the first system had no support for TCG-encrypted drives and wouldn’t let me do anything to recover.
- ASRock Taichi X670E — no support from BIOS; infinite boot loop
- Asus Crosshair X670E Extreme — password unlock supported by BIOS
I had the same problem happen.
An NVMe M.2 SSD drive is the boot drive, and the laptop has UEFI-only BIOS (no legacy BIOS mode). Right after I installed UEFI PBA image, reboot will not detect it. Since I didn't add a new password, PBA will ask for a password, but entering the default one will not start OS reboot.
I tried USB rescue64, installed rescue64 in PXEboot server, and they both do not recognize or show the NVMe M.2 drive whether running linuxpba or sedutil --scan. I also tried PXEboot a Linux network installer after which I copied over linuxpba and sedutil, and it does show /dev/nvme0 but I cannot access it, and sedutil --scan shows 'No OPAL'.
The laptop UEFI BIOS does show the drive.
The only solution I used was remove the NVMe M.2 drive, put it in a PC that uses legacy BIOS and has a SATA drive as boot drive, and I was able to access the NVMe M.2 drive and able to fully unlock it. Now I put it back in the laptop and using it in fully unlocked mode without my own passphrase.
I'm now wary of enabling locking on NVMe M.2 drive, since there is no easy way to unlock it from the UEFI-only laptop (It's a hassle to remove it, put it in a PC, and go through all that). But at least I didn't have to PSID revert (basically trash all the data).
All other Opal-2.0 enabled SATA SSDs work fine with BIOS PBA, although they were installed in mixed UEFI/legacy BIOS PCs and none were NVMe M.2 drives and none were UEFI-only PCs.