Mac mini M4 won't boot after wallpaper shuffle; DFU fails

I didn't find a home-level solution that worked — after multiple DFU restore attempts kept failing at the same stage, I brought it to an Apple Authorized Service Provider. They were able to restore it with their service-level tooling. Diagnostics confirmed the hardware was fine; it was a software/state issue that consumer-level DFU tooling couldn't handle.

Took it to an Apple Authorized Service Provider. Diagnostics came back clean, no hardware replaced. They restored the system with their service-level tooling (data wiped in the process) and the Mac came back fully functional. So in the end it wasn't a hardware issue — it was a software/state-level problem that standard end-user DFU restore couldn't recover from. Thanks for pointing me to the Apple Service Diagnostics option, that's what got me in the door.

Update for anyone finding this thread later: resolved at an Apple Authorized Service Provider. No hardware replaced, system restored with service-level tooling (data wiped). If you hit this exact pattern (4047 in Finder, Step 4 stuck in Configurator), home-level DFU attempts are unlikely to succeed — service appointment is the practical path.

Thanks for the clarification on error 4047. I’ll arrange the Apple Service Diagnostics appointment when I can, but realistically I won’t be able to bring it in for a few days, so I’d like to keep exploring home-level options in the meantime.

To focus specifically on the 4047 — in my case it occurred during the Finder restore method, in the “preparing” stage that comes after the IPSW download completes. The progress bar at that point shows the indeterminate looping animation (not actual progress), and after a long wait in this state, the error appears.

A few follow-up questions:

1. Network path: I tried switching from my home Wi-Fi (Türk Telekom ISP) to an iPhone hotspot, with the same result at the same stage. Both paths probably end up on related infrastructure once they leave the local link, but the routing should be different. Would you expect a true ISP/proxy interference issue to behave the same on both, or would mobile data typically bypass it? I’m trying to determine whether there’s still a network angle to investigate, or whether reaching this same failure on two different network paths effectively rules out the host-to-server theory.

2. DNS: I didn’t manually set custom DNS on either path — I was using the defaults provided by each network. Would changing the host Mac’s DNS to something neutral (e.g., Cloudflare 1.1.1.1) be worth trying for the Finder “preparing” stage? Specifically, does the Finder restore process use system DNS, or does it have its own resolution path for Apple’s restore servers?

3. Server-side intermittent issues: Are there known windows when Apple’s TSS / personalization servers have shown elevated failure rates that resolve after some hours? I’ve made my attempts within a relatively short window — is there a chance simply waiting a day and retrying could change the outcome, independent of anything on my side?

4. Observable signal between communication failure vs. deeper issue: From the host side, is there anything visible in the Finder process (Console logs, system log entries, etc.) that would distinguish a server/communication failure from a target-Mac-side state issue? I’d like to confirm which side is failing before I try further variations.

5. Has anyone here recovered a Mac with this exact pattern at home, using approaches like manually downloaded IPSW with a custom restore, third-party tools (e.g., iMazing), or any other procedure when standard Finder/Configurator restore keeps failing repeatedly?

I’ll continue trying viable home-level paths until I can get to service. Any pointers appreciated.