No Bootable Medium Found when mounting .vdi

[grahambo_j]

Hi,

I have a .vdi file that was previous used on version 5.2.6-120293 of VirtualBox. I can't use that version anymore because it is incompatible with newer versions of Windows. (I get a Windows error "This app can't run on this device")

When I try to open this .vdi file on my new Windows installation and an updated version of VirtualBox, I get the error "No Bootable Medium Found."

The disk file may be encrypted using the built-in VirtualBox encryption, so that may be the problem? I'm not sure how I'd go about unlocking it, all I see is the option to encrypt the drive but if anything I'd want to decrypt it. (I know the password... I think).

Thank you for your help!

[mpack]

Move the entire VM folder, not just one of the files - even if it is the biggest one.

That is especially true if the drive is encrypted, since it is impossible to recover the contents if the VDI parts company with the .vbox file.

[grahambo_j]

Move the entire VM folder, not just one of the files - even if it is the biggest one.

That is especially true if the drive is encrypted, since it is impossible to recover the contents if the VDI parts company with the .vbox file.

I'm booting the .vdi from the same folder, it's on my other hard drive as that wasn't wiped when I reinstalled Windows.

[scottgus1]

I'm booting the .vdi from the same folder

You really have to be booting the VM from the old .vbox file. A new .vbox file will not have the encryption key that completes the encryption process along with the password.

We may be posting at cross-purposes because of the terminology you're using. One does not 'boot a .vdi'. A .vdi is the VM's hard disk. Just like a real hard disk is not a whole computer, a .vdi is not the whole VM. You'd attach the .vdi to a VM, or use the .vdi as attached to the old VM. Then boot the VM.

The nuance makes all the difference when encryption is in place. The encryption key in the .vbox file must also be in place to boot the OS installed in that VM's disk. If you've attached the encrypted .vdi to a new .vbox, the encryption won't engage and the VM will fail booting with the error message you report, because the disk looks like it's filled with white noise.

Right-click the VM in the main Virtualbox window's VM list, choose Show in Explorer/Finder/File Manager. Zip the VM's .vbox file (not the .vbox-prev file), and post the zip file, using the forum's Upload Attachment tab. (Configure your host OS to show all extensions if the folder that opens does not show a .vbox file.)

[grahambo_j]

I'm booting the .vdi from the same folder

You really have to be booting the VM from the old .vbox file. A new .vbox file will not have the encryption key that completes the encryption process along with the password.

We may be posting at cross-purposes because of the terminology you're using. One does not 'boot a .vdi'. A .vdi is the VM's hard disk. Just like a real hard disk is not a whole computer, a .vdi is not the whole VM. You'd attach the .vdi to a VM, or use the .vdi as attached to the old VM. Then boot the VM.

The nuance makes all the difference when encryption is in place. The encryption key in the .vbox file must also be in place to boot the OS installed in that VM's disk. If you've attached the encrypted .vdi to a new .vbox, the encryption won't engage and the VM will fail booting with the error message you report, because the disk looks like it's filled with white noise.

Right-click the VM in the main Virtualbox window's VM list, choose Show in Explorer/Finder/File Manager. Zip the VM's .vbox file (not the .vbox-prev file), and post the zip file, using the forum's Upload Attachment tab. (Configure your host OS to show all extensions if the folder that opens does not show a .vbox file.)

This may be a stupid question: the old version 5.2.6 r120293 (Qt5.6.2) used .vbox too right?

I've attatched the .vbox file for you, I've put XXXXXX in two places for privacy reasons.

[scottgus1]

<HardDisk uuid="{35188a47-7ba5-4517-84a4-26df8b89594b}" location="Windows 10.vdi" format="VDI" type="Normal">
<Property name="CRYPT/KeyId" value="Windows 10"/>
<Property name="CRYPT/KeyStore" value="XXXXXX"/>
</HardDisk>

Looks like the encryption key is there, provided it was a lot longer than 'XXXXXX', like this one:

<HardDisk uuid="{dd9d70a4-d0b5-463d-bf19-1f779f8653f9}" location="DOS Clone-disk1.vdi" format="VDI" type="Normal">
<Property name="CRYPT/KeyId" value="DOS Clone"/>
<Property name="CRYPT/KeyStore" value="U0NORQABQUVTLVhUUzI1Ni1QTEFJTjY0AAAAAAAAAAAAAAAAAABQQktERjItU0hB
MjU2AAAAAAAAAAAAAAAAAAAAAAAAAEAAAABBlpnIA2xzN2uyV2TRRobNB+feG4QW
r+4RlvBjOWpvxSAAAADg9Njs1grsdQLHhW0b2g0R2M2zwfGqeaW8dNBJkvIiCCBO
AAAaUyD/59q8KlU0tAvMGi6ooZvkK5JkvmzAMThnnjBoV8DUAQBAAAAAQtGvaKo3
gB6yXXAJxRfkDkYRCZ7seia+ZN2VXI/we9tySXqt+61UFnLAmqrGQgYUD3RMdIGl
/VPiEDaw4iX7SA=="/>
</HardDisk>

And that this .vbox was the one that went with the .vdi.

You should be getting a popup asking for the password. If you're not, then it puzzles me why not.

[grahambo_j]

<HardDisk uuid="{35188a47-7ba5-4517-84a4-26df8b89594b}" location="Windows 10.vdi" format="VDI" type="Normal">
<Property name="CRYPT/KeyId" value="Windows 10"/>
<Property name="CRYPT/KeyStore" value="XXXXXX"/>
</HardDisk>

Looks like the encryption key is there, provided it was a lot longer than 'XXXXXX', like this one:

<HardDisk uuid="{dd9d70a4-d0b5-463d-bf19-1f779f8653f9}" location="DOS Clone-disk1.vdi" format="VDI" type="Normal">
<Property name="CRYPT/KeyId" value="DOS Clone"/>
<Property name="CRYPT/KeyStore" value="U0NORQABQUVTLVhUUzI1Ni1QTEFJTjY0AAAAAAAAAAAAAAAAAABQQktERjItU0hB
MjU2AAAAAAAAAAAAAAAAAAAAAAAAAEAAAABBlpnIA2xzN2uyV2TRRobNB+feG4QW
r+4RlvBjOWpvxSAAAADg9Njs1grsdQLHhW0b2g0R2M2zwfGqeaW8dNBJkvIiCCBO
AAAaUyD/59q8KlU0tAvMGi6ooZvkK5JkvmzAMThnnjBoV8DUAQBAAAAAQtGvaKo3
gB6yXXAJxRfkDkYRCZ7seia+ZN2VXI/we9tySXqt+61UFnLAmqrGQgYUD3RMdIGl
/VPiEDaw4iX7SA=="/>
</HardDisk>

And that this .vbox was the one that went with the .vdi.

You should be getting a popup asking for the password. If you're not, then it puzzles me why not.

Yes the key is there. I'm also puzzled. All it does is say No Bootable Medium found, no other errors or popups. I'm guessing it has something to do with old VirtualBox version.

[scottgus1]

Encryption is part of the Extension Pack. Did you install the Extension Pack in the host Virtualbox? The version numbers must match.

[grahambo_j]

Encryption is part of the Extension Pack. Did you install the Extension Pack in the host Virtualbox? The version numbers must match.

I did not have the Extension pack. I just successfully installed it and it does the same thing. I noticed in File -> Virtual Media Manager -> Information the disk in question is the only disk not attached, it says it's not encrypted, and the UUID does not match the Machine UUID located in the .vbox I sent you. Could it be as simple as editing the .vbox to change the UUID?

[scottgus1]

With encryption involved you definitely do not want to lose the .vbox file containing the key, assuming this .vbox file goes with that .vdi. The encryption key is not interchangeable.. Hopefully you kept the VM in its initial old state as a backup.

I'm not certain what else to do, since we don't know all that you've done. When using an old VM in a new Virtualbox, one merely registers the .vbox file with the new Virtualbox's Machine menu Add command (or double-click the .vbox) and the VM will be ready to run. If you deviated from this process in any way, the disk file and .vbox might have gotten orphaned from each other. This looks like it could have happened:

Virtual Media Manager -> Information the disk in question is the only disk not attached, it says it's not encrypted,

This one:

the UUID does not match the Machine UUID located in the .vbox I sent you.

The machine UUID is very often different from the disk UUID. The machine UUID is the 'motherboard' UUID, so to speak. You'd not want to change those UUIDs.

If the original VM is still in its original state, with the old .vbox file still pointing correctly at the old vdi, you should be able to unregister what you've got now and register the old .vbox file per the process above. If that .vbox file is paired correctly with the .vdi file, the VM should ask for the password then start. If it does not, then I think uour VM has been pebcaked too much over the years. It might be time to start over fresh.

[mpack]

I noticed in File -> Virtual Media Manager -> Information the disk in question is the only disk not attached, it says it's not encrypted, and the UUID does not match the Machine UUID located in the .vbox I sent you.

Every object in VirtualBox has a UUID to identify it. The VM has one, each disk has one. They do not have the same value, and the UUID displayed for a VM is the VM UUID, not the UUID of any of the disks.

The information that a certain VDI is encrypted comes from the VM configuration (the .vbox file), not from the VDI file. So if the VDI is mounted in another VM then that VM will not know that the disk is encrypted. If you enable encryption again then the drive will be double encrypted. Basically you must NEVER part the .vbox file from the VDI which it owns. Without the necessary information to decrypt the VDI the contents look like randomized junk to any unauthorized reader.

So your encrypted VDI will continue to be unusable until you place it back in its original VM. This is what encryption is: you have to be the authorised user in order to access the data. You can't be the authorized user if you can't produce the original .vbox file.

All this is what I explained very simply in my first post here (your first reply), so I'm not sure why so many more posts are needed to keep explaining the same thing. What is the hold-up in restoring the original .vbox file?

Also, if you have been continuing to mess with the VDI then I hope you made a backup, otherwise the VDI is quite possibly ruined.

[mpack]

p.s. At some point I'd like to return to the claim in the first post that VirtualBox 5.2.6 is not compatible with latest Windows. I rather doubt that is the case, in fact the 5.2.6 manual lists Win10 as a supported host. IMO this misunderstanding is usually caused by false alerts from "Program Compatibility Assistant" as a result of group policies that can be disabled.

[grahambo_j]

With encryption involved you definitely do not want to lose the .vbox file containing the key, assuming this .vbox file goes with that .vdi. The encryption key is not interchangeable.. Hopefully you kept the VM in its initial old state as a backup.

I'm not certain what else to do, since we don't know all that you've done. When using an old VM in a new Virtualbox, one merely registers the .vbox file with the new Virtualbox's Machine menu Add command (or double-click the .vbox) and the VM will be ready to run. If you deviated from this process in any way, the disk file and .vbox might have gotten orphaned from each other. This looks like it could have happened:

Virtual Media Manager -> Information the disk in question is the only disk not attached, it says it's not encrypted,

So if I double click the .vbox file I get this error: "Trying to open a VM config 'E:/Virtual Box/VM Machine/Windows 10/Windows 10.vbox' which has the same UUID as an existing virtual machine."

Also, I should have mentioned before that in VirtualBox it identified the old VM as you can see here:

virtualbox1.PNG (4.63 KiB) Viewed 4073 times

virtualbox2.PNG (8.71 KiB) Viewed 4073 times

but it has the old path, now the drive is E:, not F:.

p.s. At some point I'd like to return to the claim in the first post that VirtualBox 5.2.6 is not compatible with latest Windows. I rather doubt that is the case, in fact the 5.2.6 manual lists Win10 as a supported host. IMO this misunderstanding is usually caused by false alerts from "Program Compatibility Assistant" as a result of group policies that can be disabled.

I'd like to try that old version, do you have an idea as to how I could disable some group policies to achieve that?

I noticed in File -> Virtual Media Manager -> Information the disk in question is the only disk not attached, it says it's not encrypted, and the UUID does not match the Machine UUID located in the .vbox I sent you.

So your encrypted VDI will continue to be unusable until you place it back in its original VM. This is what encryption is: you have to be the authorised user in order to access the data. You can't be the authorized user if you can't produce the original .vbox file.

All this is what I explained very simply in my first post here (your first reply), so I'm not sure why so many more posts are needed to keep explaining the same thing. What is the hold-up in restoring the original .vbox file?

Also, if you have been continuing to mess with the VDI then I hope you made a backup, otherwise the VDI is quite possibly ruined.

This should be the original .vbox file as it is in the same folder. It sounds like the .vdi and .vbox should have just clicked with each other, but something went wrong. The way I tried to get the VM into my new VirtualBox installation was by creating a new VM but selecting the "Use an existing virtual hard disk file" option.

virtualbox3.PNG (17.72 KiB) Viewed 4073 times

I have a feeling part of the issue is that VirtualBox is getting confused that my drives are no longer F: and A: but D: and E:
Maybe this is where I went wrong and I should have clicked "Add" instead of "New". Did that irreversibly overwrite it ?

[mpack]

If you are trying to restore an existing VM then using the "Create VM" dialog is certainly not how you do it.

If you have an existing folder containing the .vbox file and related files (including the VDI) then all you need to do is double click the .vbox file to register it. The whole VM folder can be moved BEFORE registration if you need it to live somewhere else.

[scottgus1]

In addition to Mpack's thoughts above, this is the desired location for the .vdi in the attached obfuscated .vbox file above:

<HardDisk uuid="{35188a47-7ba5-4517-84a4-26df8b89594b}" location="Windows 10.vdi" format="VDI" type="Normal">

Note that the location contains no path. This means the .vdi is expected to be in the same folder as the .vbox file. If you have moved the .vdi elsewhere, that could be the reason why your first attempts to run the VM did not work.

Also, the .vbox file does not show any snapshots being used, which eases the fix.

Here is my recommendation:

1. Back up the original unobfuscated .vbox file and the original .vdi file. You're going to delete all references to these files in Virtualbox, which if done wrongly will permanently delete the files too.
2. Reboot the host so no Virtualbox processes are running.
3. Make a brand-new folder on a drive that you want the .vdi to be on. This will be the VM's folder. Move the .vdi and .vbox files to this new folder.
4. Start Virtualbox. The VM should read 'inaccessible'.
5. Right-click the inaccessible VM and delete it. If you get a pop-up box asking you to keep or delete the files, click to keep them, though you should have moved them already to a folder Virtualbox does not know about.
6. In the main Virtualbox window's File menu, Virtual Media Manager, check that there is no reference to the .vdi file. If it is listed, click Release and Remove. If you get a pop-up box asking you to keep or delete the vdi, click to keep it, though you should have moved it already to a folder Virtualbox does not know about.
7. In the Machine menu, Add command, browse to the new VM folder, and select the .vbox file.
8. The VM should now register and run, and ask you for the password.
9. If all does not go well, report what happened.