virtualbox.org

Host: macOS High Sierra 10.13.6
Guest: Ubuntu 17.10
Virtual Box: 6.0.4

I had previously created a number of bootable VDIs (Windows/different flavors of Linux) using a previous version of Virtual Box. I fired them up again after not doing so for a long time. They (all of them) failed to load. I decided to upgrade Virtual Box to the latest to see if that would fix the issue. That didn't fix the issue, so I deleted all my virtual machines and tried to create a new virtual machine. I mapped the virtual machine to my Ubuntu 17.10 VDI. When I tried to start it up I got this message:

Failed to open a session for the virtual machine Ubuntu 17.10.

The virtual machine 'Ubuntu 17.10' has terminated unexpectedly during startup with exit code 1 (0x1).

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: MachineWrap
Interface: IMachine {5047460a-265d-4538-b23e-ddba5fb84976}

I did some googling and found that this was a general error. I looked for logs in the right places but the logs weren't there. I'm guessing that VB didn't even get far enough in the process to be able to reach a state where it could write out to a log. My next step is to download an OS installer and try to start from scratch, but I wanted to know:

1. How do I check VDIs for corruption? Is there a relatively easy to mount them?
2. If the VDIs aren't corrupted, how do I trouble shoot this issue?

Thanks!

Brother Bear wrote:I had previously created a number of bootable VDIs

The idea of a "bootable VDI" doesn't sit very well, with me at least. A VDI is a Virtual Disk Image, aka a virtual hard drive. If I give you a hard drive and tell you "boot from it", chances are that if you get the rest of the "computer" wrong, it won't boot. The "computer" is the recipe of the VM, the .vbox file. They should go together with the VDI(s), they form the basis of a VM.

Brother Bear wrote:My next step is to download an OS installer and try to start from scratch

Please do that. Let's see how it goes...

Brother Bear wrote:How do I check VDIs for corruption?

There is a command line tool "vbox-img" that has a "repair" option. Haven't tried it personally:

Code: Select all

$ vbox-img 
Oracle VM VirtualBox Disk Utility 6.0.4
(C) 2005-2019 Oracle Corporation
All rights reserved.

Usage: vbox-img
   setuuid      --filename <filename>
                [--format VDI|VMDK|VHD|...]
                [--uuid <uuid>]
                [--parentuuid <uuid>]
                [--zeroparentuuid]

   geometry     --filename <filename>
                [--format VDI|VMDK|VHD|...]
                [--clearchs]
                [--cylinders <number>]
                [--heads <number>]
                [--sectors <number>]

   convert      --srcfilename <filename>
                --dstfilename <filename>
                [--stdin]|[--stdout]
                [--srcformat VDI|VMDK|VHD|RAW|..]
                [--dstformat VDI|VMDK|VHD|RAW|..]
                [--variant Standard,Fixed,Split2G,Stream,ESX]

   info         --filename <filename>

   compact      --filename <filename>
                [--filesystemaware]

   createcache  --filename <filename>
                --size <cache size>

   createbase   --filename <filename>
                --size <size in bytes>
                [--format VDI|VMDK|VHD] (default: VDI)
                [--variant Standard,Fixed,Split2G,Stream,ESX]
                [--dataalignment <alignment in bytes>]

   createfloppy --filename <filename>
                [--size <size in bytes>]
                [--root-dir-entries <value>]
                [--sector-size <bytes>]
                [--heads <value>]
                [--sectors-per-track <count>]
                [--media-byte <byte>]

   createiso    [too-many-options]

   repair       --filename <filename>
                [--dry-run]
                [--format VDI|VMDK|VHD] (default: autodetect)

   clearcomment --filename <filename>

   resize       --filename <filename>
                --size <new size>

Brother Bear wrote:Is there a relatively easy to mount them?

Starting with VirtualBox 6.0.0, there's a command line tool that allows OSX hosts (for now) to mount any VirtualBox readable disk image. Haven't tried it personally:

Code: Select all

$ vboximg-mount 
usage: vboximg-mount [options] <mount point directory path>

vboximg-mount options:

  [ { -i | --image= } <specifier> ]  VirtualBox disk base or snapshot image,
                                     specified by UUID, or fully-qualified path

  [ { -l | --list } ]                If --image specified, list its partitions,
                                     otherwise, list registered VMs and their
                                     attached virtual HDD disk media. In verbose
                                     mode, VM/media list will be long format,
                                     i.e. including snapshot images and paths.

 [ { -w | --wide } ]                 List media in wide / tabular format
                                     (reduces vertical scrolling but requires
                                     wider than standard 80 column window
)
  [ --vm=UUID ]                      Restrict media list to specified vm.

  [ { -p | --partition= } <part #> ] Expose only specified partition via FUSE.

  [ { -o | --offset= } <byte #> ]    Bias disk I/O by offset from disk start.
                                     (incompatible with -p, --partition)

  [ { -s | --size=<bytes> } ]        Specify size of mounted disk.
                                     (incompatible with -p, --partition)

  [ --rw ]                           Make image writeable (default = readonly)

  [ --root ]                         Same as -o allow_root.

  [ { -v | --verbose } ]            Log extra information.

  [ -o opt[,opt...]]                 FUSE mount options.

  [ { -h | -? } ]                    Display short usage info (no FUSE options).
  [ --help ]                         Display long usage info (incl. FUSE opts).

vboximg-mount is a utility to make VirtualBox disk images available to the host
operating system in a root or non-root accessible way. The user determines the
historical representation of the disk by choosing either the base image or a
snapshot, to establish the desired level of currency of the mounted disk.

The disk image is mounted through this utility inside a FUSE-based filesystem
that overlays the user-provided mount point. The FUSE filesystem presents a
a directory that contains two files: an HDD pseudo device node and a symbolic
link. The device node is named 'vhdd' and is the access point to the synthesized
state of the virtual disk. It is the entity that can be mounted or otherwise
accessed through the host OS. The symbolic link is given the same name as the
base image, as determined from '--image' option argument. The link equates
to the specified image's location (path).

If the user provides a base image UUID/path with the --image option, only
the base image will be exposed via vhdd, disregarding any snapshots.
Alternatively, if a snapshot (e.g. disk differencing image) is provided,
the chain of snapshots is calculated from that "leaf" snapshot
to the base image and the whole chain of images is merged to form the exposed
state of the FUSE-mounted disk.

Brother Bear wrote:2. If the VDIs aren't corrupted, how do I trouble shoot this issue?

Build the appropriate recipe for the specific VDI. Don't expect an EFI-boot disk to boot with BIOS for example. But, let's see if you have more fundamental problems after you've tried a brand new VM...

I downloaded an Ubuntu ISO and created a VM with Virtual Box connecting it to a completely new VDI. The same error that I posted above appeared here.

I then tried it in a different account on my Mac to make sure that it wasn't environmental. It didn't work there either.

Then I tried creating a test VM with no ISOs attached to the virtual optical drive just to see if it would boot. The same error that I posted above appeared here.

At this point, I thought maybe I had installed it incorrectly. I uninstalled VirtualBox with the script the installer image provides and then re-installed. The same problem reappeared.

In comparing my issue with some of what seemed to be like similar issues here and elsewhere on the web, I checked to see if I had SIP enabled. It was disabled, so I re-enabled it. Still no change.

Finally, I downgraded by installing 5.1.4 r110228. This time when I created a new VM/VDI combination, I was to get the virtual monitor (I don't know the technical term for it) to flash and then the error appeared, but this time I got this message:

Failed to open a session for the virtual machine Ubuntu 18.04 (2).

Failed to load R0 module /Applications/VirtualBox.app/Contents/MacOS/VMMR0.r0: The owner is not root: '/Applications' (VERR_SUPLIB_OWNER_NOT_ROOT).

Failed to load VMMR0.r0 (VERR_SUPLIB_OWNER_NOT_ROOT).

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: ConsoleWrap
Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

I was confused by this because the installer installed the app as root, but I'm obviously not running it as root. I ran VirtualBox as root (`sudo su -l` and then ran the executable from the command line) but I still got that same error.

I'm not sure where to go now. It feels like a permissions issue, but I don't how to troubleshoot this.

@socratis: I saw that you suggested posting the installation log from another user that seemed to have a similar problem. Here's my installation log output.

Your installation log looks fine. Post the output of the following command:

Code: Select all

ls -laed@ \
  / \
  /Applications \
  /Applications/VirtualBox.app \
  /Applications/VirtualBox.app/Contents/MacOS/VirtualBox \
  /Applications/VirtualBox.app/Contents/MacOS/VirtualBoxVM \
  /Applications/VirtualBox.app/Contents/MacOS/VBoxRT.dylib \
  /private \
  /private/etc \
  /private/etc/sudoers \
  /private/tmp \
  /Library \
  /Library/Filesystems \
  /Library/Frameworks \
  /usr/local/lib

Code: Select all

> ls -laed@ \
>   / \
>   /Applications \
>   /Applications/VirtualBox.app \
>   /Applications/VirtualBox.app/Contents/MacOS/VirtualBox \
>   /Applications/VirtualBox.app/Contents/MacOS/VirtualBoxVM \
>   /Applications/VirtualBox.app/Contents/MacOS/VBoxRT.dylib \
>   /private \
>   /private/etc \
>   /private/etc/sudoers \
>   /private/tmp \
>   /Library \
>   /Library/Filesystems \
>   /Library/Frameworks \
>   /usr/local/lib
drwxr-xr-x@  36 root   wheel      1152 Feb 15 10:20 //
	com.apple.backupd.unlockrecordUUIDs	     168
drwxrwxr-x+ 129 mikes  staff      4128 Feb 14 20:54 /Applications/
 0: group:everyone deny delete
drwxr-xr-x    3 root   admin        96 Feb 14 20:54 /Applications/VirtualBox.app/
-rw-r--r--    1 root   admin   5903952 Jan 26 02:46 /Applications/VirtualBox.app/Contents/MacOS/VBoxRT.dylib
-rwxr-xr-x    1 root   admin  33067904 Jan 26 02:46 /Applications/VirtualBox.app/Contents/MacOS/VirtualBox*
-rwsr-xr-x    1 root   admin    157264 Jan 26 02:46 /Applications/VirtualBox.app/Contents/MacOS/VirtualBoxVM*
drwxr-xr-x+  70 root   wheel      2240 Dec 24 11:52 /Library/
 0: group:everyone deny delete
drwxr-xr-x    4 root   wheel       128 Feb 14 20:54 /Library/Filesystems/
drwxr-xr-x   11 root   wheel       352 Feb 14 20:54 /Library/Frameworks/
drwxr-xr-x    6 root   wheel       192 Nov  2 09:53 /private/
drwxr-xr-x  126 root   wheel      4032 Feb 14 21:39 /private/etc/
-r--r-----    1 root   wheel      2299 Aug 23  2015 /private/etc/sudoers
drwxrwxrwt    6 root   wheel       192 Feb 15 10:22 /private/tmp/
drwxr-xr-x  418 mikes  admin     13376 Feb 14 20:54 /usr/local/lib/

Also, FYI. This is a developer machine so I have `brew` and `XCode` installed. I saw that you had asked another member what their setup was like. And just to be clear, at some point VirtualBox was working on my setup.

Brother Bear wrote:I saw that you suggested posting the installation log from another user

Brother Bear wrote:I saw that you had asked another member what their setup was like.

You got to be by far the best single user that's done their homework! KUDOS!

Brother Bear wrote:

drwxrwxr-x+ 129 mikes  staff      4128 Feb 14 20:54 /Applications/

Your /Applications owner:group are not properly setup. Somehow you became the owner, not a good idea. Here's how it should look like:

Brother Bear wrote:

drwxrwxr-x+ 129 root  admin       4128 Feb 14 20:54 /Applications/

And in order to do that, issue the command:

```
sudo chown root:admin /Applications
```

Verify the permissions. Enjoy VirtualBox...

Great! I knew it was a permissions issue!

When I turned off SIP I probably at some point accidentally changed the permissions on that directory. I noticed that you had said you do talk to the developers; one suggestion I have is in the install script to check to see that the permissions are correct on the `/Applications` directory. One of the warning notices I posted noted that, I just didn't understand what file path it was talking about.

Re: doing homework
I tried really hard to fix this problem myself so I wanted to make sure that I had done everything. I was also trying to anticipate what you might ask me to do, so I figured that might help you help me.

Thanks so much for your help. I appreciate it!

Glad you got it going. And thank you for marking the topic as [Resolved]...

Yes, VirtualBox could be doing a better job of notifying the user about the permissions. I mean it *does* check them after all. My only "concern" is that the hardening checks are happening at a way low level code and the notification is at a top level. Kind of difficult to convey the messages all the way through the chain. Just throw an error and let the head-scratching begin!

virtualbox.org

[Resolved] Unable to boot previously working VDI

[Resolved] Unable to boot previously working VDI

Re: Unable to boot previously working VDI

Re: Unable to boot previously working VDI

Re: Unable to boot previously working VDI

Re: Unable to boot previously working VDI

Re: Unable to boot previously working VDI

Re: Unable to boot previously working VDI

Re: Unable to boot previously working VDI

Re: Unable to boot previously working VDI

Re: [Resolved] Unable to boot previously working VDI