Data vanished after poweroff/poweron about sedutil HOT 6 CLOSED

Hi, @philfry

What I wrote before is from the Wiki's "Encrypting your drive" page, with my modest modification to a non-bootable drive.

I should also mention that your command:
sedutil-cli --initialSetup <yourAdmin1password> /dev/sda
left the LockingRange 0 of your disk disabled.

So don't ask me why you have anything corrupted on this drive because I don't understand at all how you achieved anything by writing data to the drive without executing the command:
sedutil-cli --enableLockingRange 0 <yourAdmin1password> /dev/sda

Also:
I've never used PSID Revert so I don't know why you had data on disk after doing it. Did you get a message after it: "revertTper completed successfully" ?

Here is my humble advice to everyone who is going/starting with sedutil-cli:
Please read the instructions on the Wiki pages first. If something is incomprehensible, or works differently than you thought, check the "Issues" pages to see if someone has already asked about it, and maybe someone else has already answered it.

ATB

from sedutil.

Sorry, I need to correct my previous message.

The command "sedutil-cli --initialSetup ..." left the LockingRange 0 disabled, but also left it set as RW, and that means it was available as for writing, and for reading as well, just the locking by power cycling was disabled. So you could write the data.

initialSetup aalso prepared disk for partition shadowing. I don;t know, if it "stole" some of the disk space for the shadow PBA partition.

I use the disk that it had many data written already, before I have used the sedutil-cli to prepare it to be locked according to the TCG Opal, including the shadow PBA partition, and I don't have any problems with the data corruption.

I think, however, that the better practice is to prepare the TCG Opal shadowing and locking first, and then to install the system and to write the data on it.

Regards

from sedutil.

Hi, @philfry

The performed by you command:

sedutil-cli --initialsetup ${passphrase} /dev/sda

left your disk with MBREnabled = Y (ON) and with MBRDone = Y (ON).

First of all, after performing that command (--initialsetup), you should do also the following commands:

sedutil-cli --enableLockingRange 0 <yourAdmin1password> /dev/sda
sedutil-cli --setLockingRange 0 LK <yourAdmin1password> /dev/sda
sedutil-cli --setMBREnable OFF <yourAdmin1password> /dev/sda

The last one from mentioned above is telling the device that it will not have the shadow MBR partition, since this is not the booting device. You should perform also

sedutil-cli --setLockingRange 0 RW <yourAdmin1password> /dev/sda

if you were going to access the data partition before making power cycle, followed by the linuxpba.

For some reason the linuxpba performed on your booting disk (/dev/nvme0) left your non-booting disk (/dev/sda) with the parameters MBREnabled = Y (ON) and with MBRDone = N (OFF), that means it gave you access to the shadow MBR partition of your data disk, that there is nothing on it (on that partition since you did nod load any PBA image to it), and which partition should not exist on non booting device.

ATB

from sedutil.

Hi @JaBoMa

Many thanks for your help!

I can access my data after issuing sedutil-cli --setMBRDone on ${passphrase} /dev/sda even though fdisk/parted tell me there's some data corruption regarting the backup gpt:

fdisk -l /dev/sda
# The backup GPT table is corrupt, but the primary appears OK, so that will be used.
# Disk /dev/sda: 931,51 GiB, 1000204886016 bytes, 1953525168 sectors
# Disk model: CT1000MX500SSD1 
# Units: sectors of 1 * 512 = 512 bytes
# Sector size (logical/physical): 512 bytes / 512 bytes
# I/O size (minimum/optimal): 512 bytes / 512 bytes
# Disklabel type: gpt
# Disk identifier: 7D59C85D-3056-274A-BB7D-6681918209D3
# 
# Device     Start        End    Sectors   Size Type
# /dev/sda1   2048 1953523711 1953521664 931,5G Linux filesystem

sgdisk -e /dev/sda
# Caution: invalid backup GPT header, but valid main header; regenerating
# backup header from main header.
# [...]
# Warning! Secondary partition table overlaps the last partition by
# 591 blocks!
# Try reducing the partition table size by 2364 entries.
# Aborting write of new partition table.

To me it looks like some hidden reserved spaces that was taken from the already allocated data partition. Dunno.

I guess it's not enough just issueing the three commands you gave me to fix my issue. Should I start over, like reverting psid, initialize, enableLockingRange 0, setLockingRange LK (what does 'LK' stand for?) and setMBREnable off, or is there an easier way possibly without data loss?

from sedutil.

Hi @JaBoMa

thanks a lot for your explanations and after reading a bit further I think most questions are answered why this happened and what I did wrong.

Kind regards

from sedutil.

fwiw: after issueing the three commands from #420 (comment) and re-writing the partition table the disk was perfectly usable again (even the reserved space came back) and it was unlocked automatically by the pba. Thanks!

from sedutil.