Updating to MacOS Monterey leads to an infinite boot sequence.

[ActuallyTaylor]

I hope this is the right place to ask this, I am not really sure of anywhere else too,

I started off using this installer to create a Catalina VM. From the Catalina VM, I used the Big Sur updater from the App Store to update the VM. This update went smoothly, so I then downloaded the beta profile for Monterey. I let the installer run and it gets to the point of rebooting to the Apple logo. Here it makes it almost to the end of the bar, but about 5/6ths of the way did when it rebooted again. This time it did not make it back to the Apple logo. It is now just stuck on a seemingly infinite sequence of logging text to the screen.

The text it is logging is,

AppleKeyStore: 1149:1266 operation failed (sel: 7 ret: e00002bc, -1, 100000)
IOConsoleUsers: time(0) 0->0, lln 0, llk 1,
IOConsoleUsers: gIOScreenLockState 3, hs 0, bs 0, now 0, sw 0x0
Failed e00002be to create GTraceBuffer cdgtrace for decoder and count 1024

I am not sure why this has happened, as the Big Sur update went all good. Is there any known fix to this? Or any possible steps I can take to update to Monterey?

[myspaghetti]

There was an issue with AppleKeyStore with the Big Sur beta too. Maybe it'll get resolved by the time Monterey hits release candidate.

Meanwhile if you still want to run Monterey you could try installing it on an empty volume (don't upgrade an existing system) and then set USB to version 1.1 and disable VM network adapters, that worked around the AppleKeyStore issues with the Big Sur beta.

[zoolino]

Sam here, clean installed Monterey on Virtual Box, installation went fine but on restart I get stuck on same error, above tips did not help. Any adive?

[myspaghetti]

The release version (12.0.1) installs, boots, and performs fine.

[myspaghetti]

After further testing, the most often-successful way to install Monterey is to download it through Software Update and select a non-system volume as the installation target. Upgrading in-place may lead to a boot loop, installing onto an empty volume seems to work more consistently.

[CalculonPrime]

The release version (12.0.1) installs, boots, and performs fine.

That's not what I'm finding. If I use the latest official image linked from this page:
https://7labs.io/tips-tricks/macos-monterey-direct-download.html
macOS Monterey 12.0.1 (21A559) / October 25, 2021
SHA256: 9630e14e5142937a08bc01dea96fead4477e5722fa8390d712ecae318acaf476

Then whether I install it as an upgrade to a working Catalina system, or install it to an empty drive, after the initial reboot, then it enters a reboot loop where it gets to the Apple logo + progress bar, and then randomly restarts after 1 or sometimes 10 minutes.

[myspaghetti]

@CalculonPrime try installing it from a working Catalina system onto an empty volume using Software Update. This should enable you to boot both Catalina and Monterey. I suspect that upgrading Catalina or installing from a bootable installer onto an empty volume upgrades the boot process, which results in boot issues. However, keeping Catalina intact and installing Monterey from Catalina onto an empty volume has consistently resulted, under my limited testing, in a working dual-boot Monterey and Catalina VM.

[CalculonPrime]

@CalculonPrime try installing it from a working Catalina system onto an empty volume using Software Update. This should enable you to boot both Catalina and Monterey. I suspect that upgrading Catalina or installing from a bootable installer onto an empty volume upgrades the boot process, which results in boot issues. However, keeping Catalina intact and installing Monterey from Catalina onto an empty volume has consistently resulted, under my limited testing, in a working dual-boot Monterey and Catalina VM.

I'm using the installer pkg mentioned above to install within Catalina to a new disk volume, so I believe that's the exact case you suggested. Catalina is not modified, yet the new disk ends up an infinite boot loop after the in-OS installation bit finishes. It boots up to the progress bar, reaches between 28%-18% complete, and then reboots.

So, not working for me.

[CalculonPrime]

Looks like the missing piece of the puzzle here is the # of CPUs you choose. If you choose 2 CPUs, it will install and boot. If you choose 4 CPUs (which my Catalina system had configured), it will loop during installation and if you toggle it on an installed Monterey system it will kernal panic and crash a few seconds after you reach the desktop (try doing 'about this computer').

So looks like VirtualBox is not handling some magic that runs with > 2 CPUs for Monterey.

[CalculonPrime]

Actually, even 2 CPUs doesn't seem to be completely stable. I've had two reboots with 2 CPUs though sometimes the system can go for hours without crashing.

[Edit: The XCode user-mode crashes I reported were the result of tweaks to the cpu declartaion in the vbox file to attempt to fix the kernel panic. So that's avoidable. But the instant reboot for > 2 CPUs and random 10 minutes - 3 hours reboot with 2 CPUs persists.]

[FlorianLeMenn]

Hello, I have the same problem, with kernel panic reboot, I try differents solutions and now it's work :
VirtualBox configuration :

VirtualBox Manage conf :
With windows command

cd "C:\Program Files\Oracle\VirtualBox"
VBoxManage setextradata "macos" "VBoxInternal/Devices/efi/0/Config/DmiSystemProduct" "iMac19,1"
VBoxManage setextradata "macos" "VBoxInternal/Devices/efi/0/Config/DmiSystemVersion" "1.0"
VBoxManage setextradata "macos" "VBoxInternal/Devices/efi/0/Config/DmiBoardProduct" "Mac-AA95B1DDAB278B95"
VBoxManage setextradata "macos" "VBoxInternal/Devices/smc/0/Config/DeviceKey" "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc"
VBoxManage setextradata "macos" "VBoxInternal/Devices/smc/0/Config/GetKeyFromRealSMC" 1
VBoxManage setextradata "macos" "VBoxInternal/TM/TSCMode" "RealTSCOffset"

tuto video : https://youtu.be/mSmpAerTNA4

[CalculonPrime]

Thanks, yes the line:

VBoxManage setextradata "macos" "VBoxInternal/TM/TSCMode" "RealTSCOffset"

seems to be what fixes things.

Now, the only remaining issue with Monterey + VirtualBox is that Recovery Mode is unreachable. If you try to "boot from file" in the VirtualBox BIOS and dive into the Recovery Partition, in Catalina there was a boot.efi file under the GUID, but not in Monterey. (Actually, I think the issue started with Big Sur but I don't have a BIg Sur VM.)

[joaomcferreira]

I have just tried the instructions given by @FlorianLeMenn and I was finally able to upgrade to Monterey without any problems. I started an installation from zero, on VirtualBox, I removed the excess files, then I ran the VBoxManage commands and the upgrade now is successful for the first time for me. I am running Debian11 with VirtualBox 6.1.32.

Thank you

[goodfellasthai]

Thanks, yes the line:

VBoxManage setextradata "macos" "VBoxInternal/TM/TSCMode" "RealTSCOffset"

seems to be what fixes things.

Now, the only remaining issue with Monterey + VirtualBox is that Recovery Mode is unreachable. If you try to "boot from file" in the VirtualBox BIOS and dive into the Recovery Partition, in Catalina there was a boot.efi file under the GUID, but not in Monterey. (Actually, I think the issue started with Big Sur but I don't have a BIg Sur VM.)

This is also what fixed it for me, I wasn't specifically setting any VirtualBox params other than the script generated ones, once I changed RealTSCOffset there was no more boot loop during the Monterey upgrade from the default Catalina install, recommend adding to the the script @myspaghetti

I added the below to the configure_vm section in the script
VBoxManage setextradata "${vm_name}"
"VBoxInternal/TM/TSCMode" "RealTSCOffset"

Also loving your work @myspaghetti - this is an amazing script for running a macOS installation on VirtualBox from Windows - top work.

[myspaghetti]

Thank you @goodfellasthai , incorporated in version 0.99.2.0

[CalculonPrime]

Has anyone here figured out how to boot into the Recovery Partition on Big Sur and later OSes? I've seen plenty of workarounds that involve creating an entire new installation to use as a recovery partition, but I'm talking about being able to boot into the actual Recovery Partition. The problem is, when you use the VirtualBox BIOS to try to boot from a file, there's no boot.efi in the Recovery Partition for Big Sur and later.

The bugs I file against VirtualBox + MacOS guests on Oracle's website don't even get triaged, as I think Oracle intentionally provides poor support for MacOS guests. So I think think filing a bug there will not accomplish anything. This github site seems to be a gathering point for people knowledgeable about VirtualBox + MacOS.

Note that there's a similar bug filed against VMware + MacOS being unable to boot into recovery in Big Sur and later OSes, so my best guess is that this originates in some formatting/structural change to the Big Sur Recovery Partition that both VirtualBox and VMware are unable to deal with. However, perhaps there is some VBoxManage setting that can be applied to cause MacOS to behave differently?

[Kamushy]

had the same issue, attempted to fix using the method by @FlorianLeMenn but it did not solve it, any help is appreciated

kamushy#0992