iMac 17,1 Recovery / Hardware Enumeration Problem — NOT a Generic “How Do I Reinstall macOS?” Issue

[Tripoutski]

Late-2015 27" iMac 17,1, Intel i5-6600 @ 3.30 GHz, 8 GB RAM.

(Edit: I know that this is a painful read, but the tech-heads that like this stuff need this sort of detail 😉)

The internal HDD is physically installed and is functioning normally. It still contains the original macOS installation and user data. Nothing has been erased or reformatted.

The objective is not data recovery. We simply want to wipe the existing installation and perform a fresh macOS Monterey installation.

The original owner is my mother, the only owner of the machine. She is no longer able to operate it, so we do not have a reliable way to authenticate to the existing account. None of the passwords available to us have worked, so I am currently locked out. This is not being presented as evidence of a password or security failure. It is simply why we are working from Recovery rather than the existing installation.

The machine's firmware is well past the known iMac17,1 170.0.0.0.0 firmware problem and has been updating normally, so that historical issue has already been ruled out.

We are currently booted into macOS Recovery, not normal macOS. Recovery itself is functioning sufficiently to provide Terminal and its own APFS/Base System environment.

The actual problem:

• Recovery is not exposing the physical storage layer.
• diskutil list shows the Recovery-related devices. A disk3 object appears, but it is not backed by a physical store.
• diskutil apfs list reports:
  • Container ERROR -69810
  • No Physical Stores
  • No Volumes
• diskutil info disk3 reports:
  • Whole: No
  • Disk Size: 0 B

Most importantly:

• diskutil list physical
• returns no physical disks at all.

Therefore this is not simply “the HDD is blank,” nor an APFS formatting problem. The existing HDD has an operating system and data on it; Recovery simply isn't exposing the underlying physical device to us.

External storage:

​

We've also attempted to use USB drives/external storage as alternate boot or installation media, with the same basic result: the Recovery environment does not make the physical external storage available to us.​

​

That makes “the internal SATA HDD has failed” an insufficient explanation. The apparent inability to access storage extends beyond the internal device.​

​

And there is another oddity:​

​

Keyboard input becomes unavailable at particular points in Recovery where input is required, including attempting to enter a Wi-Fi password. We can use Ethernet/LAN, but keyboard behavior in Recovery has been abnormal only in recovery mode. It is a wired keyboard.​

​

We are specifically interested in whether the storage-access behavior and keyboard/input behavior could have a common cause, rather than assuming they are unrelated failures.​

​

system_profiler is unavailable in this Recovery shell (command not found), which appears to be normal for this minimal Recovery environment and is not being treated as evidence of hardware failure.​

Current hypothesis:

We are not assuming a failed HDD.​

​

The working hypothesis is that something at the EFI/boot/Recovery/security-policy/environmental layer is preventing access to the physical hardware, or that some other mechanism is causing Recovery to operate without exposing the underlying devices.​

The evidence currently is:

Existing internal storage present + physical disks absent from diskutil list physical + external USB storage unavailable + Recovery itself functional + anomalous keyboard/input behavior at relevant Recovery stages.​

​

We therefore want to identify what gatekeeper or boot-environment condition could produce this behavior.​

​

We are deliberately investigating that before opening the iMac or replacing hardware.​

Please don't start with these paths:

• “Just use Recovery.”
• “Open Disk Utility and erase the drive.”
• “The HDD is probably dead.”
• “Replace the HDD.”
• Generic APFS/reinstall instructions.
• Generic “reset your password” instructions.

Recovery is precisely what we're investigating. It currently cannot see any physical disk.

We're looking for someone familiar with Intel Mac EFI/Recovery internals and hardware enumeration, who can help identify why the physical layer is unavailable rather than simply assuming the hardware behind that layer has failed.

We currently do not have another Mac. We might be able to scratch up an old iPad from somewhere if need be. We are technical, but not Mac wizards.

If anyone needs more detail, please do not hesitate to ask. This has been a head-scratcher!

 

[Bigwaff]

Opening an iMac of that vintage is pretty straight forward. Why wrestle with complexities of EFI/Recovery internals before doing hardware testing? ¯\_(ツ)_/¯

 

[Tripoutski]

Opening an iMac of that vintage is pretty straight forward. Why wrestle with complexities of EFI/Recovery internals before doing hardware testing? ¯\_(ツ)_/¯

*Devil's advocate* Why crack it when something at the hardware level is keeping us from full access to the drive, external drives, tools, and built-in safeguards have been being prevented/blocked? I can throw a new drive in there with no guarantee that we will not be blocked out of that. What is happening is at a far lower level than the HDD. So what is the proposition that you are thinking about? Cracking a case is cracking a case, no biggie (let's face it, an SSD and jamming 32GB into it would make it viable anyway, but why toss time and money on a bricked unit that will not let us in long before it gets to the OS level?).

This is certainly a learning process for me for sure, but logic is sort of dictating a lot of this nuttiness.