![]() Instead go to the location of the VM file in Finder and ctrl-click to select ‘Show Package Content’: Once the VM is created you will be presented with the following window, do not click ‘play’, do not boot the VM yet! ![]() This will make sure that the VM does not automatically boot when it’s fully created. iso instead of selecting the original installer:ĭo NOT click ‘Finish’, click ‘Customize Settings’ instead and save the VM where you want. Mv ~/Desktop/BigSur.cdr ~/Desktop/BigSur.iso Hdiutil convert /tmp/BigSur.dmg -format UDTO -o ~/Desktop/BigSur.cdr => Or force eject the mounted installer volume in Finder (Thanks Kevin for reminding me about the -force option) Sudo hdiutil detach /Volumes/Install\ macOS\ Big\ Sur -force Sudo /Applications/Install\ macOS\ Big\ Sur.app/Contents/Resources/createinstallmedia -volume /Volumes/BigSur -nointeraction Hdiutil attach /tmp/BigSur.dmg -noverify -mountpoint /Volumes/BigSur To work around this I had to create an ISO file from the installer and use that to create the VM in Fusion 12: hdiutil create -o /tmp/BigSur -size 17000m -volname BigSur -layout SPUD -fs HFS+J I’ve ran into this issue in the past, where are reboot of the host Mac fixed it, but not this time. Except one glitch which I think VMWare is aware of: Fusion 12 fails to create the installation medium when you select the macOS Big Sur Installer: I basically followed the exact same workflow as my earlier post on VM’s and Automated Enrolment, which all seems to work fine. That said, I still wanted to test the creation of a Big Sur VM, and to do so I started with VMWare Fusion 12. As general advise I’d always crosscheck your testing on a physical machine before putting anything into production, especially when you see some weird behaviour. FileVault deferral issues like deferring the _mbsetupuserĭepending what you are testing, this may all be ignorable glitches, but still things to keep in mind.Enrolment customisation not passing user info correctly to Jamf Connect.Inconsistent behaviour with Setup Assistant showing or hiding screens you select in the Jamf Pro pre-stage.Even on a high end Macbook Pro it feels a bit slow, but more problematic is the inconsistent behaviour I see from time to time. I can do this, but it's error prone and kind of a pain when I simply wanted to spin up a new VM to test something.Since the release of macOS Catalina I have mixed feelings about using a VM to test macOS deployments. Fixing this involves an arcane dance around /etc/udev/rules.d (Bonus points) On the new VM, often eth0, eth1, etc.I can't simply cut and paste the MAC into the field, so this can be an error-prone task, especially if I forget my pen and paper to write down the MAC. To fix this, I need to find the MAC address of the new VM, edit ifcfg-ethN and add this MAC to the HWADDR= field.The file /etc/sysconfig/network-scripts/ifcfg-ethN has the MAC address of the interface on the first machine. Linux doesn't know about this new MAC address and thus networking doesn't work. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |