Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Software Update to install Tahoe 26.7 fails on a blank screen
- Thread starter OscarA11
- Start date
Macintosh Rescue
Member
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?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?
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.
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 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:
2. Back the file up first. This is the undo button:
3. Find the two firmware slots:
You should get two lines, like mine:
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):
New in slot 1, old in slot 2 (Wade's case):
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:
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:
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:
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:
Code:
cd "/Volumes/YourDisk/Parallels/YourVM copy.macvm"2. Back the file up first. This is the undo button:
Code:
cp -p aux.bin aux.bin.bak3. Find the two firmware slots:
Code:
strings -a -t x aux.bin | grep -E '[im]Boot-[0-9]'You should get two lines, like mine:
2401e mBoot-18000.161.1022401e mBoot-20457.1.29The 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):
Code:
dd if=aux.bin of=aux.bin bs=16384 skip=9 seek=137 count=128 conv=notruncNew in slot 1, old in slot 2 (Wade's case):
Code:
dd if=aux.bin of=aux.bin bs=16384 skip=137 seek=9 count=128 conv=notrunccount=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:
Code:
sysctl hw.memsize hw.memsize_usableThe 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:
Code:
cp -p aux.bin.bak aux.binTwo 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:
Code:
dd if=/path/to/old/aux.bin of=aux.bin bs=16384 skip=9 seek=137 count=128 conv=notrunc