search

bacongravy / macinbox

Puts macOS in a Vagrant box
Other
662 stars 45 forks source link

Support - macOS 10.15 Catalina installer #38

Closed egandro closed 5 years ago

egandro commented 5 years ago

I will do a go/nogo installation with this

egandro commented 5 years ago

Iso won't boot in Vmware...

milch commented 5 years ago

I tried the installation with the following options, using the latest VMware 11:

sudo macinbox --short catalina-test --full User --password 123456 --installer /Applications/Install\ macOS\ 10.15\ Beta.app --use-qemu

Got this log output: 

• Checking macOS versions...
  + Warning: host OS version (10.14.5) and installer OS version (10.15) do not match
• Creating image from installer...
  + Creating and attaching wrapper disk image...
  + Creating and attaching a new blank disk image...
  + Installing macOS...
    - installer: 100% done

• Cleaning up...
Traceback (most recent call last):
        11: from ~/.rbenv/versions/2.6.3/bin/macinbox:23:in `<main>'
        10: from ~/.rbenv/versions/2.6.3/bin/macinbox:23:in `load'
         9: from ~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/macinbox-3.3.0/exe/macinbox:5:in `<top (required)>'
         8: from ~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/macinbox-3.3.0/lib/macinbox/cli.rb:19:in `run!'
         7: from ~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/macinbox-3.3.0/lib/macinbox/cli.rb:122:in `start'
         6: from ~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/macinbox-3.3.0/lib/macinbox/cli.rb:122:in `chdir'
         5: from ~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/macinbox-3.3.0/lib/macinbox/cli.rb:128:in `block in start'
         4: from ~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/macinbox-3.3.0/lib/macinbox/logger.rb:17:in `info'
         3: from ~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/macinbox-3.3.0/lib/macinbox/cli.rb:129:in `block (2 levels) in start'
         2: from ~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/macinbox-3.3.0/lib/macinbox/actions/create_image_from_installer.rb:49:in `run'
         1: from ~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/macinbox-3.3.0/lib/macinbox/actions/create_image_from_installer.rb:112:in `create_rc_vagrant'
~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/macinbox-3.3.0/lib/macinbox/actions/create_image_from_installer.rb:112:in `write': No such file or directory @ rb_sysopen - /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_image_from_installer.ZAEvtMe6/scratch_mountpoint/private/etc/rc.installer_cleanup (Errno::ENOENT)
egandro commented 5 years ago

I tried just the ISO not via macinbox.

At this point the VM didn't start, yet - just the Installer was called to write the content to a disk.

So could be the same issue. So VMWare needs to solve this :)

bacongravy commented 5 years ago

Thanks, @egandro, for looking into this and sharing your findings. I haven't had a chance to dig into Catalina support. I did find this thread which has some workarounds for getting Catalina to work in Fusion:

https://communities.vmware.com/thread/611961

The error that macinbox reported:

create_image_from_installer.rb:112:in `write': No such file or directory @ rb_sysopen - /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_image_from_installer.ZAEvtMe6/scratch_mountpoint/private/etc/rc.installer_cleanup (Errno::ENOENT)

...is probably because Catalina changes how the root filesystem works, and it is no longer okay to create files in /private/etc. I'm hopeful that once I learn more about how Catalina works that I'll be able to identify a workaround.

bacongravy commented 5 years ago

I have reproduced this issue. The following directories do not exist on the volume created by the Catalina installer:

/private/etc
/private/etc/sudoers.d
/Library/Preferences

The script fails when it tries to write files to these locations.

epackorigan commented 5 years ago

There appears to be "templates" for a lot of the files around this path, inside the image: /System/Library/Templates/Data

egandro commented 5 years ago

Someone managed to get this working with VMWare:

macOS 10.15 Catalina Installer (Beta 1 19A471t)

bacongravy commented 5 years ago

I hacked on macinbox to add a /System/Library/Templates/Data prefix to all the relevant paths and was able to create a box, but when I boot the box with VMware it gets about 80% through the startup progress bar and then the VM spontaneously powers off. I tried booting verbosely but didn't see any relevant messages before the VM stopped.

egandro commented 5 years ago

We have to figure out how to create / patch a specific nvram file :( This issue can be solved with a -v boot arg parameter.

adamwolf commented 5 years ago

I think we can borrow some things from here! https://github.com/AlexanderWillner/runMacOSinVirtualBox

bacongravy commented 5 years ago

@adamwolf Contributions are welcome! However, I'm not sure what we can borrow from that project that I haven't already. The difficultly here isn't in getting macOS to boot in a VM, but in getting that VM automatically configured to be a valid vagrant box.

The macinbox tool is somewhat unique in that it attempts to perform the installation of the OS on the host, rather than inside of a VM. In order to configure the installed OS to be usable by vagrant the tool needs to lay down some files in locations projected by SIP, which is very hard to do once the installed OS is running. You'll note that runMacOSinVirtualBox doesn't automate the installation of the OS or the creation of user accounts at all. You have to manually click through the installer after the VM boots for the first time!

egandro commented 5 years ago

Someone tried a new beta?

egandro commented 5 years ago

I got Beta7 booting with this "trick":

https://communities.vmware.com/thread/611961

But the installed OS still does not boot :(

egandro commented 5 years ago

Officially announced: https://blogs.vmware.com/teamfusion/2019/08/vmworld-2019-fusion-and-workstation-announcements.html

Fusion 11.5 comes with macOS 10.15 Catalina

I guess we have to wait for a few weeks...

egandro commented 5 years ago

Fusion 11.5 is out now!

https://blogs.vmware.com/teamfusion/2019/09/vmware-fusion-11-5-available-now.html

bacongravy commented 5 years ago

Thanks, @egandro ! I haven't had a chance to try the new Fusion yet, or the latest Catalina, but I will soon.

I did see that AutoDMG needed to make a change for Catalina: https://github.com/MagerValp/AutoDMG/commit/c55bbcfbc27683e9cdd60cc8989f14dd73b9e6cc

...which looks like it addresses: https://github.com/MagerValp/AutoDMG/issues/234

bacongravy commented 5 years ago

I did some more testing with the latest Catalina and Fusion using a Mojave host. I can install and run Catalina in Fusion if I create the VM using Fusion from the Catalina installer app. However, if I create a box with a hacked (that is, with paths prefixed with /System/Library/Templates/Data) version of macinbox it powers off part way through booting in Fusion. According to the logs it seems that the Data volume isn't getting mounted. I'm starting to wonder if the Mojave installer actually knows how to install Catalina properly. The next thing to try is to use the hacked macinbox from a Catalina host and see if the created box behaves differently.

bacongravy commented 5 years ago

I tested with Catalina 19A582a as both the host and installer version, and macinbox mostly works as-is. The box is created and boots fine, but the VMware guest kernel extensions don't get loaded properly.

bacongravy commented 5 years ago

I was able to boot Catalina with Parallels and VirtualBox, too, using an unmodified macinbox to create the boxes from a Catalina host.

I then recreated a VMWare box and it started hanging at the end of the boot process. My suspicion is that the broken VMWare tools kernel extensions were somehow blocking the boot process. (I don't know why sometimes they are reported as broken after booting, whereas other times they apparently just cause a hang.) I was able to work around the issue by re-creating the Catalina VMWare box again, this time without the tools installed or the KextPolicy file updated.

bacongravy commented 5 years ago

I am also observing that the HiDPI setting is not preserved when vagrant brings up the VMWare box. When you try to bring up a VMWare box and then inspect the virtual machine with VMWare Fusion the HiDPI setting is not enabled. The setting appears properly in the original VMX file in the box, but the cloned VMX file has the setting lowercased, and it is not respected. If you power off the VM and change the setting with VMWare Fusion it updates the VMX and puts the capitalization of the setting correctly again. If you power the VM back on with VMWare Fusion the setting is preserved. However, if you run vagrant up again, then the setting gets lowercased again, and the VM boots without HiDPI support.

Works: gui.fitGuestUsingNativeDisplayResolution = "TRUE" Does not work: gui.fitguestusingnativedisplayresolution = "TRUE"

This appears to be long-standing vagrant behavior so I think this may be a regression introduced by VMWare Fusion 11.5.

bacongravy commented 5 years ago

Confirmed, the HiDPI issue does not occur with 11.1.0. I have filed #44 to track the issue.

bacongravy commented 5 years ago

Here's my current thinking for how to resolve this issue:

bacongravy commented 5 years ago

It also turns out the Catalina hosts cannot create Mojave (or earlier) boxes, so we'll need to prevent that, too.

bacongravy commented 5 years ago

I've begun to address this on a catalina branch. I'm targeting this for the v4.0.0 milestone.

bacongravy commented 5 years ago

I have addressed this with https://github.com/bacongravy/macinbox/commit/019c999bd088b3ced0c15a19ec5f06dcca11a8d9.

bacongravy commented 5 years ago

v4.0.0 has been released. Closing.