An Evening At The (Genius) Bar

The adventures involved in attempting to reload a fresh copy of Big Sur on a 2020 iMac that was fully erased spanned a multi-day effort which involved trying everything under the sun. All established procedures for signing out of Apple accounts and services were followed without issue. Attempts to reinstall macOS using Recovery (Catalina) and Internet Recovery (Catalina and Big Sur) were unsuccessful. Resetting the PRAM and SMC did nothing to overcome the issue, nor did a DFU revive or restore. A potential StackExchange workaround for restoring the internal SSD using a fresh install on an external drive didn’t pan out. Accessing a bootable USB drive that contained the Big Sur installer via Terminal also resulted in a failure at the same “14 minutes remaining” timestamp in the setup GUI.

The minimal clues that something wasn’t quite right with the system involved an exceptionally sluggish UI experience during the navigation to initiate acceptance of the license agreement. These behaviors did not manifest when attempt to perform a local recovery or Internet Recovery (Shift-key modifier in tandem with Option-Command-R) for the current-at-time-of-manufacturing Catalina install. Other references that point to these errors stemming from a lack of space didn’t apply here as the SSD was erased and offered up 1TB of capacity. While the install process was smoother from a UI perspective with Catalina, the second reboot always returned the following error.

The native diagnostic tool built into the system executed and returned a No Issues Found result.

After four days of trying everything possible under the sun, which included more obscure items such as the DFU revive/restore, blessing the volume, and booting into single user mode, I accepted defeat and called support. The instructions to execute repeated everything that was already done. Ultimately, this iMac would need to take a trip to the Genius Bar. Once again, explaining everything that had been attempted was dismissed and their initial troubleshooting steps mirrored everything that was done over the past four days. The additional tools that Apple does not allow consumers to utilize resulted in a finding. The system in question had 64GB (4x16GB) of G.Skill Ripjaws memory installed on Day 1 and has worked without issue between the upgrade from Catalina to Big Sur and all subsequent point releases up to 11.6. The secondary tool indicated that the memory modules that were installed in the lowest two SODIMM slots were unhealthy.

This is not the first time that an event with this memory has been experienced. A comparable issue with a Core i5 2018 Mac mini would result in an inability to wake from sleep or boot after a year of service. Reinstalling the original memory resolved the issue with the Mac mini and the OS Recovery process would have most likely been successful on the 2020 iMac had an indicator been present within the baseline diagnostic tools. While anecdotal in nature, this is the third event we’ve experienced with this specific brand and model of SODIMM memory on an Apple platform.

The key install log text that alluded to a possible memory error was visible at the end of a failed Recovery process. The specific error messages included:

iMac osinstallersetupd[594]: Operation queue failed with error: Error Domain=com.apple.OSInstallerSetup.error Code=1004 “An error occurred loading the update., NSUnderlyingError=0x7ff2a55cda40 {Error Domain=SZExtractorErrorDomain Code = 2 “CRC mismatch; got: 0x2900f6d4 expected: 0x5d56388d for file AssetData/payloadv2/payload.004, SZExtractorFileOffsetErrorKey=4251340446, SZExtractorSourceFileLineErrorKey=1339, NSFilePath=AssetData/payloadv2/payload.004, SZExtractorFunctionNameErrorKey=-[StreamingUnzipper _supplyBytes:length:withReply:}}}

iMac osinstallersetupd[594]: Stopped operation queue with Error Domain=com.apple.OSInstallerSetup.error Code=1004 “An error occurred loading the update.” UserInfo={NSLocalizedDescription=An error occurred loading the update., NS UndelyingError=0x7ff386409540 {Error Domain=SZExtractorErrorDomain Code=2 “CRC mismatch; got: 0x5d56388d for file AssetData/payloadv2/payload.004” UserInfo={SZExtractorFunctionNameErrorKey=-[StreamingUnzipper _supplyBytes:length:withReply:], SZExtractorFileOffsetErrorKey=421340446, SZExtractorSourceFileLineErrorKey=1339, NSFilePath=AssetData/payloadv2/payload.004, NSLocalizedDescription=CRC mismatch; got: 0x2900f6d4 expected: 0x5d56388d for file AssetData/payloadv2/payload.004}}}

Lessons learned through this event:

1.) The failure rate on G.Skill Ripjaws SODIMMs are rather high based on experiences with Apple and non-Apple platforms. Support from G.Skill is fantastic and RMA turnaround times are very reasonable. However, spending a bit extra for some Crucial or Kingston memory that is certified for a given system or platform is a worthwhile endeavor which will result in fewer early-life failures based on years of experience for Mac and PC platforms.

2.) Apple would benefit from opening more of the available tools to its customers or integrating a more thorough Diagnostics option that would aid in pinpointing the problem at hand. If access to the same summarized report were available as part of the non-Genius Bar troubleshooting toolset, the issue could have been resolved with a dramatic time savings and enablement of parallel service restoration processes (initiating the RMA on the potentially faulty SODIMM modules).

3.) Apple will not accept shipping an iMac to a repair depot as an option for support as part of AppleCare+. When one purchases a luxury vehicle, the dealership maintains a fleet of loaners, shuttle service, and other amenities that justify the price premium over the standard brand. The cost of time spent troubleshooting + trip to the Apple Store + the cost of time for the store associate to redo every baseline test that was repeatedly performed and documented > printing a label to allow shipment. Many of the other Tier 1 PC vendors offer this option for applicable systems.

The option to pull the two identified DIMMs was not offered or executed while at the Genius Bar. The iMac remains at the Apple Store alongside what I’m presuming to be a considerable backlog of other problematic systems that are in need of repair. What would have been ~20 minutes of effort to rule out the finding was not offered/performed. The waiting game begins and an update will be provided once the system is ready for pickup.

Update (11/25/2021): The root cause for this issue involved the faulty memory modules that were identified during the advanced diagnostics which are only available at the Apple Store. They effectively sat on the system for over two weeks before doing EXACTLY what was proposed regarding pulling the faulty memory and executing another system restore.