vboxmanage startvm gives exit code 1, 0x80004005, but VBoxHeadless works

[Brian of the Pines]

Hi,

I somehow managed to break my virtual machine in such a way that it won't start via vboxmanage anymore, but still runs fine if I use VBoxHeadless to start it, and the webservice can still start it. Only vboxmanage startvm is somehow broken. Some info:

• Host OS is Debian Buster 64-bit.
• Guest OS is Windows 7 Ultimate 32-bit.
• VBoxHeadless --version gives 6.0.10r132072.
• VBox.log does not get anything written to it.
• I am doing all these things from an unprivileged account.
• The full error from vboxmanage is:

  Code: Select all

  Waiting for VM "6bccd736-8f53-4ee3-a155-eaaa3b61dbcb" to power on...
  VBoxManage: error: The virtual machine 'mymachine' has terminated unexpectedly during startup with exit code 1 (0x1)
  VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MachineWrap, interface IMachine

I've looked for ways to try to get more information about what exactly is going wrong, but I've come up empty-handed. What problems can cause vboxmanage to generate this error while VBoxHeadless runs the vm just fine?

Additional note: This started after inadvertently killing the VBoxSVC process on the host while VBoxHeadless was running the VM. So I have no doubt that something somewhere got corrupted by that, but I don't know how to figure out what it is or how to fix it. The host machine has been fully rebooted at least twice since, and the problem persists.

I have tried restoring a snapshot I had, and copying the ".vbox-prev" file in place of the main ".vbox" file but neither of those had any positive effect.

Also of note, all of the other vboxmanage commands to alter the VM's state or configuration seem to complete without error; it's only the case of starting the VM where it fails.

Thanks in advance for any and all input!

[mpack]

? Snapshots are alternate states for the guest OS, they will do absolutely nothing to solve host problems.

The usual reason for VBoxHeadless to work but normal start to fail is that there is some kind of problem with the host graphics or audio drivers. Does the VM start if you disable 3D acceleration? Or audio? Does Win7 start in safe mode?

If you want to continue this discussion then I'll need a VM log. With the VM fully shut down, right click it in the GUI. Select "Show Log" and save "VBox.log" (no other file) to a zip file. Attach the zip here.

[socratis]

VBox.log does not get anything written to it.

Then we need to take a look at your "/home/<you>/.config/VirtualBox/VBoxSVC.log". ZIP it and attach it to your response.

I am doing all these things from an unprivileged account.

Good, that's what you're supposed to do. VirtualBox doesn't provide additional power if you're root. On the contrary, since all VM registration is within the boundaries of the user that uses VirtualBox, being another user (even root) means that you won't be able to see your normal registered VMs. So never, ever do something as 'root', or 'sudo', except installing/uninstalling VirtualBox.

[Brian of the Pines]

The usual reason for VBoxHeadless to work but normal start to fail is that there is some kind of problem with the host graphics or audio drivers. Does the VM start if you disable 3D acceleration? Or audio? Does Win7 start in safe mode? [...] With the VM fully shut down, right click it in the GUI.

Sorry, I failed to mention this detail in the original post: The host machine is completely headless. X isn't even installed. There is no 3D acceleration or audio, or GUI to right-click, or any "normal start" for the VM that isn't headless. Not to mention that the VM was running fine prior to the onset of this particular problem, so a host driver problem seems very unlikely.

I thank you both for taking the time to respond, but in my flailings at this problem, I've managed to get to a point where the VM won't boot the guest OS at all anymore; if I start VBoxHeadless now and connect to its console with RDP, I see "FATAL: Could not read from the boot medium! System halted." So I've decided to cut my losses and start over from an old export of the VM I did a while back.

Side note: I also have an issue where a powered-down VM gets stuck in the "Snapshotting" state when that snapshot process is started via the web service, but that might be a topic for a separate thread.

[Brian of the Pines]

Oh my goodness, I'm an idiot.

I've been forgetting the "--type headless" argument to the "vboxmanage startvm" command. I expect that's what made mpack assume it wasn't a headless environment.

So that's why vboxmanage wouldn't start it but the other approaches would. Seems like there ought to be a more useful error message in that situation, but maybe it's hard to detect that specific problem in situ.

That doesn't, of course, explain some of the other issues I've been seeing, but those are topics for other threads.