Support - macOS 10.15 Catalina installer

Question

Support - macOS 10.15 Catalina installer

egandro opened this issue 5 years ago · 26 comments

egandro commented 5 years ago

I will do a go/nogo installation with this

Answer 1 · 2019-06-07T19:41:14.000Z

Iso won't boot in Vmware...

Answer 2 · 2019-06-07T21:58:25.000Z

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)

Answer 3 · 2019-06-08T09:26:11.000Z

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 :)

Answer 4 · 2019-06-19T19:09:24.000Z

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.

Answer 5 · 2019-06-21T23:46:11.000Z

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.

Answer 6 · 2019-06-25T06:07:19.000Z

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

Answer 7 · 2019-06-25T17:43:26.000Z

Someone managed to get this working with VMWare:

macOS 10.15 Catalina Installer (Beta 1 19A471t)

Answer 8 · 2019-06-27T04:27:04.000Z

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.

Answer 9 · 2019-06-27T14:53:49.000Z

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

Answer 10 · 2019-06-30T18:45:02.000Z

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

Answer 11 · 2019-07-08T21:45:14.000Z

@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!

Answer 12 · 2019-08-27T17:29:40.000Z

Someone tried a new beta?

Answer 13 · 2019-08-30T13:21:32.000Z

I got Beta7 booting with this "trick":

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

But the installed OS still does not boot :(

Answer 14 · 2019-09-17T16:17:11.000Z

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...

Answer 15 · 2019-09-20T19:46:26.000Z

Fusion 11.5 is out now!

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

Answer 16 · 2019-09-23T19:54:03.000Z

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: MagerValp/AutoDMG@c55bbcf

...which looks like it addresses: MagerValp/AutoDMG#234

Answer 17 · 2019-10-02T20:16:49.000Z

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.

Answer 18 · 2019-10-06T00:07:14.000Z

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.

Answer 19 · 2019-10-06T19:48:39.000Z

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.

Answer 20 · 2019-10-06T20:18:03.000Z

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.

Answer 21 · 2019-10-06T21:11:09.000Z

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

Answer 22 · 2019-10-06T21:17:37.000Z

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

Prevent pre-Catalina hosts from attempting to create a Catalina-or-later box
Don't install the VMWare tools into Catalina-or-later guests
Set the virtualHW and guestOS values in the VMX based on the installer OS version

Answer 23 · 2019-10-07T07:15:29.000Z

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

Answer 24 · 2019-10-07T07:20:01.000Z

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

Answer 25 · 2019-11-13T06:04:48.000Z

I have addressed this with 019c999.

Answer 26 · 2019-11-13T06:05:45.000Z

v4.0.0 has been released. Closing.