Software Update to install Tahoe 26.7 fails on a blank screen

[WesleyD2]

Letting the update process run overnight for 2 nights did not work for me.

 

[Macintosh Rescue]

So, interestingly I was curious about whether 26.7.1 would solve the problem, and...
I forgot that I had a VM running the update process (from 26.6.2).

Interestingly, I got on to my computer this morning and my VM was sitting at at 26.7.1. And is seemingly responsive. My host is also 27.0.1

So, for anybody having this problem, maybe try letting the update process run overnight?

Didn't work for me. I have a theory though: Hypervisors expose the real processing hardware and I'm wondering if the Apple Silicon chip has an effect on this. I've been trying an M2 Pro and an M5 Pro. What chip where you using when you got that update to work?

 

[BrianJ21]

It's not the chip. Host M3 Max on 27.0, Parallels 27.0.2, guest 26.6.2 -> 26.7 (25G229): same black screen as everyone here, and the same on M2 Pro, M5 Pro, M3 Ultra, M2 Max, M4 hosts in this thread and the UTM/VirtualBuddy ones. The cause is in the update payload, not the host.

What's happening: the 26.7 / 26.7.1 / 27.0 / 15.8 updates all carry new VM firmware, mBoot 20457.1.29. The updater writes it into the VM's auxiliary storage (aux.bin in the .macvm bundle) during the first post-reboot phase. Booting under that firmware leaves the guest about 1.75 GB of usable RAM (the rest is wired as boot-stolen), and the updater's next boot can't run in that, so it hangs black. Power-cycle and the guest boots the old OS but on 1.75 GB, which is the "molasses" people report. Deleting NVRAM variables or wiping NVRAM doesn't help; only the firmware bytes matter. Full analysis: Wade Tregaskis, "The macOS Sequoia 15.8 updater limits VMs to 1.75 GiB of RAM", and UTM issue #7897.

How I got a working 26.7 guest, on a Finder duplicate of the VM:

1. Attempt the update, let it black-screen, power the VM off.

2. On the host: strings -a aux.bin | grep -E '[im]Boot-[0-9]' showed two slots, 18000.161.10 at 0x2401e and the new 20457.1.29 at 0x22401e. NVRAM in the same file had IASCurrentInstallPhase=Boot 1 and upgrade-boot-volume set.

3. Copy the old firmware slot over the new one, leaving NVRAM alone: dd if=aux.bin of=aux.bin bs=16384 skip=9 seek=137 count=128 conv=notrunc (offsets are per file; check yours with the strings line first. Back the file up.)

4. Boot: guest came up on 26.6.2 with full memory (hw.memsize_usable matched hw.memsize), firmware 18000.161.10.

5. Run Software Update again. It completed. Guest is now 26.7 (25G229), firmware still 18000.161.10, full memory, aux.bin byte-identical to before the retry. The installer treated the firmware phase as already done and ran only the OS phase, which is why the retry works and a fresh attempt doesn't.

26.7.1 ships the same firmware, so expect the same dance for it. Filed with Apple as FB24965907.

 

[AdamV2]

@BrianJ21 Great explanation, thank you. Could you please elaboroate on step 3? Like how exactly do you do it?

 

[BrianJ21]

@AdamV2 Sure. Everything below is done on the HOST, with the VM fully shut down (not suspended), on a Finder duplicate of the VM so there is nothing to lose. Do it right after a failed attempt (black screen, then Stop), because that is when the file has both the old and the new firmware in it.

1. Open Terminal and go into the VM bundle. In Parallels the file is aux.bin inside the .macvm. In UTM it is Data/AuxiliaryStorage inside the .utm. Adjust the path to yours:

cd "/Volumes/YourDisk/Parallels/YourVM copy.macvm"

2. Back the file up first. This is the undo button:

cp -p aux.bin aux.bin.bak

3. Find the two firmware slots:

strings -a -t x aux.bin | grep -E '[im]Boot-[0-9]'

You should get two lines, like mine:

2401e mBoot-18000.161.10
22401e mBoot-20457.1.29

The number on the left is a hex offset. Each slot starts 0x1e before the version string, so 2401e means the slot starts at 0x24000 and 22401e means 0x224000. The one with 18000.x is the OLD firmware (good), the one with 20457.x is the NEW firmware (the problem). Which slot holds which can differ between VMs. Mine had old in the first slot and new in the second; Wade Tregaskis's VM was the other way round.

4. Convert the slot starts to 16 KB blocks: 0x24000 is block 9, 0x224000 is block 137. Those are the only two values you will ever see with this layout. Now copy the old slot over the new one. skip is the OLD slot's block, seek is the NEW slot's block:

Old in slot 1, new in slot 2 (my case):

dd if=aux.bin of=aux.bin bs=16384 skip=9 seek=137 count=128 conv=notrunc

New in slot 1, old in slot 2 (Wade's case):

dd if=aux.bin of=aux.bin bs=16384 skip=137 seek=9 count=128 conv=notrunc

count=128 is exactly 2 MB, the size of one slot. conv=notrunc is essential; without it dd truncates the file. Nothing outside the slot is touched, which is what keeps the NVRAM variables intact. Deleting NVRAM variables or wiping NVRAM does not fix this; only the firmware bytes matter.

5. Check it worked. Run the strings line from step 3 again. Both lines should now show 18000.161.10.

6. Boot the VM. Inside the guest run:

sysctl hw.memsize hw.memsize_usable

The two numbers should be within a few dozen MB of each other. If usable is around 1.8 GB the revert did not take. Then run Software Update again. For me it completed, and the guest ended up on 26.7 with the firmware still on 18000.161.10 and full memory.

If anything goes wrong at any point:

cp -p aux.bin.bak aux.bin

Two cases where you should stop and ask rather than run dd: the offsets in step 3 do not end in 01e, or the two are not exactly 0x200000 apart (that means a layout I have not seen). Or step 3 shows only ONE line and it says 20457: then the old firmware is not in the file any more and you need a pre-update copy of aux.bin, from Time Machine or from a Parallels snapshot's Snapshots/{GUID}.bin, and you copy block 9 from that file instead:

dd if=/path/to/old/aux.bin of=aux.bin bs=16384 skip=9 seek=137 count=128 conv=notrunc

 

[Keshav Dosieah]

Hello All,

Thank you for your feedback.
Please note that the issue was already submitted to our Engineering team for further investigation.
Additionally, we also recommend that you also report the same issue to Apple as well so they can investigate on their side as well.

Kind Regards,
Parallels Team

 

[kushNYC]

I encountered this issue a month ago when I updated a pair of VMs to macOS 15.8. With the help of my LLM, I was able to narrow down the cause and the solution, and an awareness that I must cold shutdown my macOS VMs, backup aux.bin, start cold, and only then apply a software update. Sadly, I had forgotten about this issue tonite when I applied 15.8.1 and encountered the same freeze post-update. Fortunately, Time Machine keeps regular backups of aux.bin and I was able to recover again, and cold start and update without issue.

I am disappointed the issue still exists after at least a month, and that I must remain conscious of this workflow for many weeks between updates. I am aware the issue exists for other macOS virtualization products. One would hope Apple sees this as a critical issue, but evidently not.

So in the meantime, I'd suggest Parallels push out some kind of update that protects the user from this issue without messing with the macOS VM guest's environment.

I know it's not optimal to include for the long term in the Parallels Desktop for Mac codebase, but until Apple addresses the problem here's what my LLM suggests:

a sound Parallels mitigation would be host-side:

1. Add a “Prepare for macOS Update” command that cleanly shuts down, backs up aux.bin, and cold-starts the guest.
2. When Tools notices an OS update being staged, automatically preserve aux.bin before the restart.
3. On the next VM start, inspect aux.bin for a known-bad firmware build such as mBoot-20457.1.29.
4. If detected, stop startup and offer “Restore previous VM firmware” or “Continue anyway.”
5. Maintain a compatibility list and warn about affected macOS update builds.