Error: The DEK for this disk is missing

[Ullus Parvus]

Hi altogether,

I wanted to enlarge my guests (system config: see signature) disk which has encryption enabled from 40 up to 60 GB.
So due to backup reasons I copied the .vdi-file to another location on my host. Then I submitted the command

Code: Select all

sudo VBoxManage modifyhd xxx.vdi --resize 61440

After that I booted the VM into a GParted Live where I resized the encrypted partition of the guest.
Now, when I boot the VM, I type in the encryption phrase, select the OS in GRUB and the following error occurs

Code: Select all

(...)
end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
(...)

In the VBox.log it says

Code: Select all

00:00:03.303860 Console: VM runtime error: fatal=false, errorID=DrvVD_DEKMISSING message="VD: The DEK for this disk is missing"

I learned that the DEK is the data encryption key with which the VM was encrypted.
The VM configuration file (xxx.vbox-prev) contains the DEK

Code: Select all

<HardDisk uuid="{e5add2a5-a55e-439b-ab02-8ca206f74558}" location="xxx.vdi" format="VDI" type="Normal">
          <Property name="CRYPT/KeyId" value="xxx"/>
          <Property name="CRYPT/KeyStore" value="....."/>
        </HardDisk>

Does anybody have an idea how to fix this?
May I be screwed up because the DEK in the config file is the encryption key for the original .vdi, which was altered through my copy and enlargement operations?

Many thanks in advance. Regards,
Ullus Parvus

[socratis]

May I be screwed up because the DEK in the config file is the encryption key for the original .vdi, which was altered through my copy and enlargement operations?

Yes. Do you have a backup? If not, I'm not sure that there's a lot you can do. Encrypted VDIs do not exist as a standalone entity, they go together with their corresponding .vbox file.

[Ullus Parvus]

Do you have a backup?

Yes, I have copied the .vdi-file before doing the enlargement-operation. But when I put the backed-up, original .vdi-file back in the VM folder I get the same errors (kernel panic and "The DEK is missing").

Encrypted VDIs do not exist as a standalone entity, they go together with their corresponding .vbox file.

Then could you think of why the above approach (putting the original .vdi in the original VM folder) results in the same errors?

[socratis]

Because the .vbox file got altered and is missing the key???
Could you zip it and post it? Do you have a .vbox-prev file? Does it have the key? Do NOT launch VirtualBox before checking and backing it up.

[Ullus Parvus]

Could you zip it and post it? Do you have a .vbox-prev file? Does it have the key?

I got both the .vbox and the .vbox-pref of the original VM, they both have the key. I attached them.

[socratis]

The key is still there, you're right. I don't know why it would complain if you did a pure file-copy for the backup (did you?). What's the output of:

• VBoxManage showmediuminfo /<yourVMdir>/vUbuntu1604_MAUS.vdi

[Ullus Parvus]

I don't know why it would complain if you did a pure file-copy for the backup (did you?)

Yes, I did a pure file-copy.

What's the output of:

VBoxManage showmediuminfo /<yourVMdir>/vUbuntu1604_MAUS.vdi

Code: Select all

UUID:           e5add2a5-a55e-439b-ab02-8ca206f74558
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       /home/christoph/VirtualBox VMs/vUbuntu1604_MAUS/vUbuntu1604_MAUS.vdi
Storage format: VDI
Format variant: dynamic default
Capacity:       40960 MBytes
Size on disk:   38994 MBytes
Encryption:     enabled
Cipher:         AES-XTS256-PLAIN64
Password ID:    vUbuntu1604_MAUS
Property:       CRYPT/KeyId=vUbuntu1604_MAUS
Property:       CRYPT/KeyStore=U0NORQABQUVTLVhUUzI1Ni1QTEFJTjY0AAAAAAAAAAAAAAAAAABQQktERjItU0hB
MjU2AAAAAAAAAAAAAAAAAAAAAAAAAEAAAADDbQ89KFWdCYDZVEGMDDKDKshP+ils
bXpr7fejczs00CAAAADMKs2Y1NbHOWW5E0XJzpdeI+HVEvVUXl5RbUDXXdFBNyBO
AAD9oq8a+3XKWiESWa37GadgQrRO50/F2wwDSxnWxA3i3eAiAgBAAAAAhYW3pmB+
BN5h13vEOVLhn4fSYltiVN2vRQdqB56zl5n94Ec/Qg0qgcRDfpck3/YKCEFPu3UA
OXB3uwldy89QoQ==
In use by VMs:  vUbuntu1604_MAUS (UUID: 2387995d-6a5b-41d9-87b9-731f4c36a233)

[Perryg]

I wonder if one can actually enlarge a drive that is encrypted. Seems to me that would change things that the encryption software would deem as suspicious. I don't encrypt virtual guests so can’t answer that myself, but it would be interesting to test if decrypting before increasing and then encrypt the guest again after it has been modified would answer that.

[Ullus Parvus]

I wonder if one can actually enlarge a drive that is encrypted

After submitting the

Code: Select all

    sudo VBoxManage modifyhd xxx.vdi --resize 61440

command there was no warning or sth like this.

but it would be interesting to test if decrypting before increasing and then encrypt the guest again after it has been modified would answer that.

I think this would have been a better approach... I'll remember this if the actual disk is lost. But maybe socratis can help me, I m still a bit confident

[socratis]

Same here Perryg, I've never dealt (or planning to deal) with encrypted VDIs. And that's a very good question that you asked to which I do not have the answer as well. Only test on non-essential guests could tell us...

One "funny" thing I noticed however while analyzing the OP's data is that in the ".vbox" file, the key is stored as a big one-line chunk. But... here's the kicker; whenever there's a new-line-character (at every 64 characters) in the "showmediuminfo" command, in the .vbox file there is a "
" entity inserted. So, this:

U0NORQABQUVTLVhUUzI1Ni1QTEFJTjY0AAAAAAAAAAAAAAAAAABQQktERjItU0hB
MjU2AAAAAAAAAAAAAAAAAAAAAAAAAEAAAADDbQ89KFWdCYDZVEGMDDKDKshP+ils
bXpr7fejczs00CAAAADMKs2Y1NbHOWW5E0XJzpdeI+HVEvVUXl5RbUDXXdFBNyBO
AAD9oq8a+3XKWiESWa37GadgQrRO50/F2wwDSxnWxA3i3eAiAgBAAAAAhYW3pmB+
BN5h13vEOVLhn4fSYltiVN2vRQdqB56zl5n94Ec/Qg0qgcRDfpck3/YKCEFPu3UA
OXB3uwldy89QoQ==

turns into this (I've highlighted the characters inserted):

U0NORQABQUVTLVhUUzI1Ni1QTEFJTjY0AAAAAAAAAAAAAAAAAABQQktERjItU0hB

MjU2AAAAAAAAAAAAAAAAAAAAAAAAAEAAAADDbQ89KFWdCYDZVEGMDDKDKshP+ils

bXpr7fejczs00CAAAADMKs2Y1NbHOWW5E0XJzpdeI+HVEvVUXl5RbUDXXdFBNyBO

AAD9oq8a+3XKWiESWa37GadgQrRO50/F2wwDSxnWxA3i3eAiAgBAAAAAhYW3pmB+

BN5h13vEOVLhn4fSYltiVN2vRQdqB56zl5n94Ec/Qg0qgcRDfpck3/YKCEFPu3UA

OXB3uwldy89QoQ==

all in one line, I simply broke it here cause it's easier to see. I really have not got the faintest idea why would someone keep the line breaks in the key, but it works...

I did a quick test with a FreeDOS guest (I love the size of those things for quick and dirty experiments). No problem. I really don't know what's going on in 'Ullus Parvus' case. Any chance that you get a "VBox.log" when you try to open that VM? A ZIPPED attachment could potentially show us a little bit more, but (unlike you) I'm not too optimistic...

Can't you decrypt the copy? What happens if you try?

Next thing: I'm going to enlarge my FreeDOS_clone and see what happens...

[socratis]

After submitting the

Code: Select all

    sudo VBoxManage modifyhd xxx.vdi --resize 61440

command there was no warning or sth like this.

SUDO? Why "sudo"? You most probably don't even have access to that file. Could you please repeat the exact procedure that you followed? Down to every little detail, every little command, every little comma?

[Perryg]

I have no reason to doubt that the actual resize would succeed since that portion does not care about the content of the drive. It is just this would scramble the content IMHO and that would make the guest fail. But didn't I read that you made a backup of this first. This should be the first step before doing anything as dangerous as changing the size of a drive. I even made this warning in the tutorial I made on drive size resize. See How to resize a Virtual Drive

[socratis]

Next thing: I'm going to enlarge my FreeDOS_clone and see what happens...

Well, nothing happened. Guest is up and running with no problems. Before:

VBoxManage showmediuminfo /Users/Shared/VirtualBox/Machines/FreeDOS\ Clone/FreeDOS\ Clone.vdi 
UUID:           4c345fb9-0a5b-4d1c-928b-f103afc88c89
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       /Users/Shared/VirtualBox/Machines/FreeDOS Clone/FreeDOS Clone.vdi
Storage format: VDI
Format variant: dynamic default
Capacity:       500 MBytes
Size on disk:   110 MBytes
Encryption:     enabled
Cipher:         AES-XTS256-PLAIN64
Password ID:    FreeDOS Clone
Property:       CRYPT/KeyId=FreeDOS Clone
Property:       CRYPT/KeyStore=U0NORQABQUVTLVhUUzI1Ni1QTEFJTjY0AAAAAAAAAAAAAAAAAABQQktERjItU0hB
MjU2AAAAAAAAAAAAAAAAAAAAAAAAAEAAAACsuweeXEjQ924b6swMKbPvt5uxx2nH
ozWOshBKdlCkKCAAAAClpD0cYX+3J0lRW21zwZDErxjCY334GNdAzEz+I2oS+CBO
AACP3F/8tcBa4e0Fxk5f+kXjETU/MiGT3DFz1CJKDM2yZ+AiAgBAAAAAfIZSXn7C
QjwGlLgna4RpXtTW1H5wYKEJ05Fh9ZsySa30nKlAYPGMC9v/kdHrarh0S4o5BnJo
l/HFR5+HRuqw3A==
In use by VMs:  FreeDOS Clone (UUID: 55044ac6-bb4a-4c37-bb82-240157e7b1d9)

and after. I highlighted the only difference between them:

VBoxManage showmediuminfo /Users/Shared/VirtualBox/Machines/FreeDOS\ Clone/FreeDOS\ Clone.vdi 
UUID:           4c345fb9-0a5b-4d1c-928b-f103afc88c89
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       /Users/Shared/VirtualBox/Machines/FreeDOS Clone/FreeDOS Clone.vdi
Storage format: VDI
Format variant: dynamic default
Capacity:       512 MBytes
Size on disk:   114 MBytes
Encryption:     enabled
Cipher:         AES-XTS256-PLAIN64
Password ID:    FreeDOS Clone
Property:       CRYPT/KeyId=FreeDOS Clone
Property:       CRYPT/KeyStore=U0NORQABQUVTLVhUUzI1Ni1QTEFJTjY0AAAAAAAAAAAAAAAAAABQQktERjItU0hB
MjU2AAAAAAAAAAAAAAAAAAAAAAAAAEAAAACsuweeXEjQ924b6swMKbPvt5uxx2nH
ozWOshBKdlCkKCAAAAClpD0cYX+3J0lRW21zwZDErxjCY334GNdAzEz+I2oS+CBO
AACP3F/8tcBa4e0Fxk5f+kXjETU/MiGT3DFz1CJKDM2yZ+AiAgBAAAAAfIZSXn7C
QjwGlLgna4RpXtTW1H5wYKEJ05Fh9ZsySa30nKlAYPGMC9v/kdHrarh0S4o5BnJo
l/HFR5+HRuqw3A==
In use by VMs:  FreeDOS Clone (UUID: 55044ac6-bb4a-4c37-bb82-240157e7b1d9)

So, resizing an encrypted hard drive works as expected. Something else is going on here...

[Perryg]

Ah well that answers that. As I said I have never tried it so thanks for testing.

[Ullus Parvus]

SUDO? Why "sudo"?

I read in forum/tutorial that someone had permission problems while executing the command. But you're right, I should have better tried it without sudo. But I have permission to the file, I checked the permissions after your hint.

Could you please repeat the exact procedure that you followed? Down to every little detail, every little command, every little comma?

I'll try.

• 1. Backup -> pure file-copy of the .vdi (to a temp location), done by GUI, not by CLI
  2. sudo VBoxManage modifyhd xxx.vdi --resize 61440
  3. downloaded a gparted live iso, set it in the VM settings as medium to boot from
  4. started the VM, booted from the iso
  5. used the 20 GB unallocated space to resize the encrypted partition of the disk with gparted --> clicked on the partition and dragged it with the cursor up to 60 GB, then clicked "Apply" --> no errors or warnings
  6. shut the VM down
  7. changed the boot order in the VM settings to boot from disk
  8. booted the VM
  9. after typing in the encryption phrase, the "kernel panic" error appeard
  10. found the "The DEK for this disk is missing" error in the VBox.log