virtualbox.org

So it appears macOS 10.14 Mojave (as of beta 1) only installs to APFS regardless if the hard drive is SSD or not.

Unfortunately, this means that VirtualBox doesn't support Mojave.
Is there a workaround for this?

Did you actually try it, or are you going solely based on that article?

I can confirm that vitualbox does not currently work on Mojave.
it throws a few kext errors.

@pSouper
As a guest, not as a host. This thread is about 10.14 as a guest. Moving it to "OSX Guests" from "OSX Hosts pre-releases".

I can confirm that using macOS 10.14 Mojave as a guest doesn't work due to missing APFS support. Simple script to test:

Code: Select all   Expand viewCollapse view

#!/usr/bin/env bash
#
# DESCRIPTION
#
# Run macOS 10.14 Mojave in Virtualbox.
#
###############################################################################


# Core parameters #############################################################
readonly INST_VER="Install macOS 10.14 Beta"
readonly INST_BIN="/Applications/$INST_VER.app/Contents/Resources/createinstallmedia"
readonly DST_DIR="/tmp"
readonly DST_DMG="$DST_DIR/macOS-Mojave.dmg"
readonly DST_VOL="/Volumes/macOS-Mojave"
readonly DST_ISO="$DST_DIR/macOS-Mojave.iso.cdr"
readonly VM="macOS-Mojave"
readonly VM_DIR="${HOME}/VirtualBox VMs/$VM"
readonly VM_SIZE="32768"
###############################################################################

# Define methods ##############################################################
runChecks() {
  echo "Running checks..."
  if [ ! -x "$INST_BIN" ] ; then echo "ERROR: '$INST_BIN' not found."; exit 1; fi
  if ! type VBoxManage >/dev/null 2>&1 ; then echo "ERROR: 'VBoxManage' not installed."; exit 2; fi
}

createImage() {
  echo -n "Creating image '$DST_DMG' (will need sudo)..."
  if [ ! -e "$DST_DMG" ]; then
    echo "."
    hdiutil detach "/Volumes/$INST_VER/" 2>/dev/null || true
    hdiutil create -o "$DST_DMG" -size 10g -layout SPUD -fs HFS+J && \
    hdiutil attach "$DST_DMG" -mountpoint "$DST_VOL" && \
    sudo "$INST_BIN" --nointeraction --volume "$DST_VOL" && \
    hdiutil detach "/Volumes/$INST_VER/"
  else
    echo "already exists."
  fi
  echo -n "Creating iso '$DST_ISO'..."
  if [ ! -e "$DST_ISO" ]; then
    echo "."
    hdiutil convert "$DST_DMG" -format UDTO -o "$DST_ISO"
  else
    echo "already exists."
  fi
}


setupVM() {
  if [ ! -e "$VM_DIR" ]; then
    mkdir -p "$VM_DIR"
  fi
  echo -n "Creating VM '$VM_DIR/$VM.vdi'..."
  if [ ! -e "$VM_DIR/$VM.vdi" ]; then
    echo "."
    VBoxManage createhd --filename "$VM_DIR/$VM.vdi" --variant Standard --size "$VM_SIZE"
  else
    echo "already exists."
  fi
  echo -n "Creating VM '$VM'..."
  if ! VBoxManage showvminfo "$VM" >/dev/null 2>&1 ; then
      echo "."
      VBoxManage createvm --register --name "$VM" --ostype MacOS_64
      VBoxManage modifyvm "$VM" --usbxhci on --memory 4096 --vram 128 --firmware efi --chipset ich9 --mouse usbtablet --keyboard usb
      VBoxManage storagectl "$VM" --name "SATA Controller" --add sata --controller IntelAHCI --hostiocache on
      VBoxManage storageattach "$VM" --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium "$VM_DIR/$VM.vdi"
      VBoxManage storageattach "$VM" --storagectl "SATA Controller" --port 1 --device 0 --type dvddrive --medium "$DST_ISO"
  else
      echo "already exists."
  fi
}

runVM() {
  echo -n "Starting VM '$VM'..."
  if ! VBoxManage showvminfo 'macOS-Mojave'|grep "State:"|grep -i running > /dev/null ; then
    echo "."
    VBoxManage startvm "$VM" --type gui
    echo "Next steps:"
    echo "  1. Partition the virtual drive"
    echo "  2. Install macOS on the virtual drive"
    echo "  3. Remove virtual macOS installer CD-ROM"
    echo "  4. Todo: Can only boot manually once to continue setup (see this file) as APFS is now enforced"
#   Shell> fs1:
#   FS1:\> cd "macOS Install Data"
#   FS1:\macOS Install Data\> cd "Locked Files"
#   FS1:\macOS Install Data\Locked Files\> cd "Boot Files"
#   FS1:\macOS Install Data\Locked Files\Boot Files\> boot.efi
  else
    echo "already running."
  fi
}

cleanup() {
  local err="${1:-}"
  local line="${2:-}"
  local linecallfunc="${3:-}"
  local command="${4:-}"
  local funcstack="${5:-}"
  if [[ "$err" -ne "0" ]]; then
    echo 2>&1 "ERROR: line $line - command '$command' exited with status: $err."
    echo 2>&1 "ERROR: In $funcstack called at line $linecallfunc."
    echo 2>&1 "DEBUG: From function ${funcstack[0]} (line $linecallfunc)."
  fi
}

main() {
  runChecks
  createImage
  setupVM
  runVM
}
###############################################################################

# Run script ##################################################################
[[ "${BASH_SOURCE[0]}" == "${0}" ]] && trap 'cleanup "${?}" "${LINENO}" "${BASH_LINENO}" "${BASH_COMMAND}" $(printf "::%s" ${FUNCNAME[@]:-})' EXIT && main "${@:-}"
###############################################################################



I'm puzzled. What would VirtualBox support for APFS consist of?

VirtualBox is a hardware emulator. It doesn't know anything about guest OS filesystems.

VirtualBox is simulating the UEFI as well. Here, in order to boot to macOS, you need to add the file system driver apfs.efi to the boot loader.

mpack wrote:VirtualBox is a hardware emulator. It doesn't know anything about guest OS filesystems.

I was of the same thinking as well. But I realized that in order to boot in EFI, you'd have to have a rudimentary filesystem parser. The APFS part isn't there yet...

To be clear, the ISO part boots fine (@Alex_, I haven't gone through your script yet), the first part of the installation works fine, the second stage works fine, but after that you're stuck...

socratis wrote:

mpack wrote:VirtualBox is a hardware emulator. It doesn't know anything about guest OS filesystems.

I was of the same thinking as well. But I realized that in order to boot in EFI, you'd have to have a rudimentary filesystem parser. The APFS part isn't there yet...

You have to support whatever filesystem is used by the boot partition (which is separate from the OS main partition). I have a sneaky feeling that the norm is FAT for the boot partition, but I could be wrong and/or it could be optional (i.e. up to the BIOS to determine).

Is APFS encumbered by patents? Forget about VirtualBox supporting it if so. If the trend of this conversation is correct then this sounds like an attempt by Apple to ringfence their own ecosystem. I don't know why, since it still sounds perfectly hackable.

The installation has three phases:

1. Preparation via ISO (no APFS involved)
2. Installation from disk incl. automatic conversion to APFS
3. Post installation (this one doesn't work)

Afaik, the UEFI part resides on a FAT partition provided by VirtualBox and it need file system drivers (ntfs, ext2, hfs+, apfs, ...) to boot the kernel from the designated drive. Might be possible to boot Mojave using another UEFI implementation such as Clover...

Alex_ wrote:Afaik, the UEFI part resides on a FAT partition provided by VirtualBox

No, VirtualBox does not put any formatting or any files on any disk ever. Your guest OS's format tool does that.

VirtualBox does provide an EFI compatible BIOS which must be able to read GPT boot partitions (aka EFI System Partition aka ESP), which AFAIK are always FAT formatted if they adhere to the UEFI standard. A secondary boot loader put there by your OS installer is what needs to understand the filesystem used in non-ESP partitions.

mpack wrote:You have to support whatever filesystem is used by the boot partition (which is separate from the OS main partition)

The filesystem is browseable all right, that part is done. The EFI partition in a typical OSX installation (and I think for everything EFI), is a 200 MB, FAT32 partition with the "boot" and "ESP" (EFI System Partition) flags. You can read it and get the "appropriate" boot file. But, as with all things Apple, they had to make it "different". From the source code (/src/VBox/Devices/EFI/Firmware/IntelFrameworkModulePkg/Library/GenericBdsLib/InternalBdsLib.h):

Code: Select all   Expand viewCollapse view

#if !defined (EFI_REMOVABLE_MEDIA_FILE_NAME)
    #if defined (MDE_CPU_EBC)
        //
        // Uefi specification only defines the default boot file name for IA32, X64
        // and IPF processor, so need define boot file name for EBC architecture here.
        //
        #define EFI_REMOVABLE_MEDIA_FILE_NAME L"\\EFI\\BOOT\\BOOTEBC.EFI"
    #else
        #error "Can not determine the default boot file name for unknown processor type!"
    #endif
#endif

#ifdef VBOX
    /**
      Apple seems to have a different EFI_REMOVABLE_MEDIA_FILE_NAME value, so it
      seems we have to check for both the apple value and for the UEFI value if we
      want to support both apple and non-apple systems.  (Probably more to this.)
    **/
    #define VBOX_EFI_APPLE_MEDIA_FILE_NAME L"\\System\\Library\\CoreServices\\boot.efi"
#endif


And then? Where do you boot from? I wish (and so does everybody) that it was as simple. It's so complicated compared to the old BIOS, it's not even a joke. And Apple is not making things easier, being Apple and everything...

For example, as 'Alex_' pointed out, after 10.13, phase 1 of the installation creates the recovery partition and reboots. In theory, you're supposed to boot from the HD (the recovery partition). In practice, it boots from the CD. Even if you remove the CD, you got to manually select the file to boot from. See [HowTo] Install OSX 10.13 in a VM, parts 6 and later. Same thing with the updates.

Now, for the 10.14 specifically, Apple has not changed the standard location of the "boot.efi" from "/System/Library/CoreServices/boot.efi", which has been the case since who knows when.

What has changed AFAIK, is that Apple doesn't provide the APFS_filesys driver in the EFI partition, hence making it impossible to read the filesystem that you're supposed to boot from.

mpack wrote:Is APFS encumbered by patents? Forget about VirtualBox supporting it if so.

Hmm... Interesting question. Here's what an older, archived FAQ from Apple has to say about that:

Is APFS open source?
An open source implementation is not available at this time. Apple plans to document and publish the APFS volume format specification.

Oh boy... I think I'm going to have to register in one of those Hackintosh forums after all..

There is an open-source, reverse-engineer attempt to read (only) an APFS filesystem; apfs-fuse (haven't tried it). And there is the Paragon APFS driver, again read-only.

Given that there is no easy, reliable way to even mount an EFI partition so that we can make heads or tails out of it, this is going to be an uphill battle, with lots of hacking involved. And a few broken NDAs...

The APFS driver is available in the macOS installer under /usr/standalone/i386/apfs.efi. I'd assume that VMWare Fusion is using this file to boot from an macOS 10.14 partition (which is working flawlessly/automatically). I managed to boot from the APFS converted drive in VirtualBox using Clover and this EFI driver. However, after invoking /System/Library/CoreServices/boot.efi the process hangs somewhere in the middle.

socratis wrote:Given that there is no easy, reliable way to even mount an EFI partition so that we can make heads or tails out of it, this is going to be an uphill battle

I'm not quite sure what you mean there... The GPT disk layout is documented in the UEFI specification, which can be downloaded for free (see UEFI spec v2.7, chapter 5). And the layout is actually quite straightforward. It should be a trivial matter for any disk sector tool to navigate the contents of a GPT drive (I've done it myself for the next version of CloneVDI).