Get rid of VERR_FILE_NOT_FOUND - could not open medium

[xoblautriv]

With every startup, VirtualBox complains that "one or more virtual hard disks, CD/DVD or (...) are currently not accessible."
The "Virtual Media Manager" indeed says he cannot open "<myoldpath>/VBoxGuestAdditions_4.0.8.iso".

This is absolutely right -- since the missing .iso file was moved to the more convenient path /usr/shared/virtualbox/VBoxGuestAdditions.iso (I've noticed late this is a standard place expected by VirtualBox.)

But how can I tell VirtualBox to forget the old path, to get rid of the persisting error message ?

I've already re-installed the guest additions, using the new file location in /usr/shared/virtualbox. But the Virtual Media Manager still complains "could not open the medium <myoldpath>/VBoxGuestAdditions_4.0.8.iso. The Virtual Media Manager has some "remove" and "release" actions which look promising. But both are always greyed out, not matter whether the VM is running or powered off.

Ruben

-------
VirtualBox 4.0.8 on a Debian Wheezy AMD64 host, the guest is a 32 Bit Ubuntu.

[mpack]

File | Virtual Media Manager, choose "CD/DVD Images" tab, click release (if not grayed out), then remove. I don't see how both can be grayed out.

[xoblautriv]

Both are greyed out. (There is a third action named "refresh" - this one only is available.)

Why could these actions be grey all the time ?

(I'll wait somewhat for a hint, and eventually create a bug report.)
--
Ruben

[mpack]

"Release" grayed out usually means that the image is not currently attached to a VM. "Remove" grayed out usually means that the disk can't be removed because the image is still attached to a VM. It's hard to see how both conditions can be true.

As a last resort I suppose you can edit the xml that contains this entry - you may need to search to find it. Also delete any references to its UUID.

[xoblautriv]

That worked.
I've found
~/VirtualBox VMs/<vmname>/<vmname>.vbox

which is an XML file. It looks like

Code: Select all

<VirtualBox ...
  <Machine ..
    <MediaRegistry ...
      <DVDImages ...
        <Image uuid=... location=xxx.iso/>
        <Image uuid=... location=yyy.iso/>

I've removed the unwanted one of these <Image ... /> tag lines, and the problem is solved (OK, in fact this should work around a minor bug )
Thank you !
Ruben

[xoblautriv]

To complete the fix: I nearly missed to remove all uuid references ...
The uuid occurs always in <Image ../> tags, with the following scheme:

Code: Select all

<StorageController name="IDE Controller" ..
  <AttachedDevice ...
    <Image uuid=THE_REMOVED_UUID ...

Would you remove just these AttachedDevice tags (leaving a StorageController tag without contents), or remove the whole StorageController tags ?

Ruben

[Sasquatch]

If you remove the storage controller part, you essentially tell the VM that the controller no longer exists. This can cause problems if you have the boot drive on it, want to load a new CD or ISO to the VM. It can even crash the Guest OS, depending on the OS you run in it and how tolerant it is.

The only reason I can think of that has both release and remove greyed out, is if the ISO was loaded in one of the snapshots of a VM. Since you can't change settings of a snapshot, only it's current state, you can't release the image. Since you cannot release the image, you can't remove it either. It would break the snapshot tree if the image is required or something is loaded from it when the snapshot was taken.

[mpack]

I would remove just the AttachedDevice part.

As Sasquatch said, you probably had the ISO mounted in a snapshot, making a return to that point in time a bit tricky. So now is the time to divest yourself of unwanted snapshots.

[xoblautriv]

That's it. A snapshot (or two) depends on that old location.
(Aah. A snapshot can, this way, depend on file structures of the host system ! I erroneously assumed it to be more self-contained.)

Solution1: Probably, I could restore these old snapshots, modify, save that modified shot, and delete the old shots...
Solution 2: Pragmatically restore the old .iso location, to ensure integrity of the old snapshots. A symbolic link should do. I'll prefer that solution.
-- Thank you --
Ruben