VirtualBox

Ticket #19929 (awaitsfeedback defect)

Opened 9 months ago

Last modified 7 months ago

VMs only start in headless mode on Big Sur

Reported by: tyll Owned by:
Component: other Version:
Keywords: Cc:
Guest type: other Host type: Mac OS X

Description

I’m using the latest beta of Big Sur (20A5384c) and the latest test build of VirtualBox (6.1.15 r140592 (Qt5.6.3)). I was able to overcome the errors caused by unloaded kernel extensions as posted elsewhere here; however, I can only start virtual machines in headless mode. Normal mode gives me a generic error of NS_ERROR_FAILURE (0x80004005) in MachineWrap and detachable mode doesn’t seem to react at all. This applies to both the GUI and VBoxManage.

Steps to reproduce:

  1. Make a new VM. It doesn’t need a boot disc or hard drive.
  2. Load it in normal or detachable mode.
  3. Notice that in normal mode, an error appears, and in detachable mode, VirtualBox seems to ignore the button press.
  4. Now try the same VM in headless mode. It will boot.

I’m using a 2018 Mac mini. I saw in VBox.log that the last thing shown before the VM errors out is about resizing a window:

Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=720 h=400 bpp=0 cbLine=0x0 flags=0x0 origin=0,0

Expected results:

I should get a window with the VM's display, even if I have no bootable media attached. The BIOS should still show, but it doesn't.

Attachments

w7test2-2020-09-29-21-15-45.log Download (112.7 KB) - added by tyll 9 months ago.
VBox.log

Change History

Changed 9 months ago by tyll

VBox.log

comment:1 Changed 7 months ago by paulson

  • Status changed from new to awaitsfeedback

There were further changes made during the development of VirtualBox 6.1.16 for macOS Big Sur which happened after 6.1.15 r140592 so can you upgrade to 6.1.16 and see if that helps? Note that with macOS Big Sur you'll have to reboot when updating VirtualBox. Also, double check the Privacy Settings before and after reboot as some users report different behaviour here on Big Sur in ticket #19795. If VMs still fail then can you attach an updated VBox.log from 6.1.16 along with the output from the commands in:

https://www.virtualbox.org/ticket/19795#comment:13
https://www.virtualbox.org/ticket/19795#comment:14

That will help root cause the issue here.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use