The author did not test the DFU flow, so I'm not sure why they're blaming the DFU port documentation.

Certainly there is a bug in the external disk upgrade sequence if switching the disk to a different (also non-DFU? They didn't specify) port solved their problem. But that's not necessarily related to which port is the DFU port.

To be clear, DFU (Device Firmware Upgrade) is a standard USB protocol (from 2004!), for a device to receive upgrades from a host. It is a specific port on the mac because that's all the boot-rom can support. This system does not come into play when booting from or upgrading an external disk, as the author was struggling with, because the external disk cannot be a USB Host to drive the DFU.

And I'm guessing that the reason macOS doesn't give more details is because macOS is likely not involved in the step that fails (maybe iBoot is?), and they didn't develop a way for the failing step to communicate failure data back to macOS. Yet another UX failure.

  Situation:
  - The author is running macOS ARM64  
  - off of a USB disk  
      - plugged into DFU capable USB-C port    
      - that shouldn't be the DFU one according to docs
  - attempting to run macOS updater  
  - (supposedly)there's nothing else connected to it  

  Outcomes:  
  - updates were failing and rolling back with cryptic errors  
  - errors persist despite all efforts  
  - -> later magically solved after changing the port  
  - -> the problematic port later revealed to be the DFU port  
      - contradictory to Apple documentation

          - plugged into DFU capable USB-C port

I have dealt with M1 Max and M4 Max MacBook Pros DFU mode many times[1], and the documentation is accurate. The primary DFU port is definitely what Apple says. I don't know, other ports may or may not exhibit DFU-like capabilities also; if so that would be unsupported and does not change correctness of Apple documentation.

UPDATE: nevermind--removed a paragraph as it does not appear the root cause is which port is DFU, but a misunderstanding of the DFU process by the blogpost.

[1]: at least once per every iOS/macOS device I have purchased to protect against software supply chain attacks when you receive a laptop in mail. DFU-restoring Apple software ensures that the OS you run is not tampered with as long as there is no bootrom exploit or hardware modification.

Regardless of whether the DFU port documentation is technically wrong or the author misdiagnosed the root cause, the real failure here is that macOS silently spent an hour "installing" an update, then rolled back without any actionable error message. No "hey, try a different port." No diagnostic log surfaced to the user. Just a vague "some updates could not be installed" notification with a "Details" button that shows no details. Apple knows which port each device is connected to. Apple knows which port is the DFU port. If there's a known incompatibility with external disk updates on that port, the OS should refuse to start the update with a clear message, not waste an hour of the user's time and silently fail. This is the kind of UX regression that erodes trust in the platform, especially for power users who are exactly the audience booting from external disks.

The author complains "For some damn reason, it matters which port your external disk is plugged into when you install or update macOS".

The reason is simple and perfectly understandable.

DFU is very low level. It happens very early in during Boot ROM and before the Mac has even entered Low-Level Bootloader. Which is why its also USB-C with no Thunderbolt support.

Boot ROM code is, by necessity and for robust security, kept to a bare minimum.

Bus 0 Receptacle 1 is designated the DFU port in the Boot ROM.

Hence the limitation to one port.

Widening support to >1 port would mean you would have to introduce extra logic into the Boot ROM code (port iteration, conflict resolution etc.).

Hence the K.I.S.S. principle wins. One port.

It's so frustrating when software knows that something is wrong and won't tell you what it is. "An error occurred". Oh, did it now? "There's nothing you can do about it except hit this X. We couldn't be bothered to think about this case or provide you with any information whatsoever that would be useful to either you or future us to diagnose it. Not even an internal code. Not a line number or even a file! But it did occur nonetheless, and we have interrupted your workflow to let you now that it did. And we're not even sorry."

All documentation is wrong, well, nearly all!

I have been booting from external drives on different hardware since 2007. I was even able to trick Windows XP to boot off of a 12GB SanDisk thumb drive. (Although it was horribly slow!)

Coming back to the author's story, as others have pointed out as well, I do not think it is related to the DFU port itself. I think it depends on the BIOS/UEFI firmware which is addressing those ports, and then the bootloader who is responsible for finding the system (root) volume.

Nowadays these happen with Volume UUIDs hence it should not matter, at least in theory. But even GRUB adds a hint, as discovery just with UUID may fail.

Since we cannot see what actually is happening or see the logs, I would simply say: "Always use the same port for booting and installation." Which usually simplifies the process.

I am quite certain "the undocumented DFU port" was the port author initially used to install macOS to the external drive. Maybe on another Mac/machine. When they change the machine, addressing/enumeration of ports may be different, due to how boot process works. Therefore, let's say you used the port=0x3 in the first install, when you change the machine, you need to find the same port=0x3. Thus being the undocumented-DFU-port author mentions.

> P.S: Also DFU port is for installing firmware (BIOS/UEFI) to the device even before boot occurs. For example, you should connect one end of a USB cable to a working computer (ie. "master"), another end to the DFU port of target (ie. "slave") while the machine that is off. Some specific sequence of power-key combination puts target machine into DFU-mode, where you can overwrite the firmware (UEFI/BIOS, etc) from the working machine... That is the purpose of DFU. -- Or at least access the internal hard-drive/SSD without actually booting the "slave" machine.

This feels like a perfect example of Apple's modern "it just works… until it very much doesn't"

[dead]

> By the way, Software Update in System Settings allowed my Mac to go to sleep during the “Preparing” phase, despite the fact that the battery was charged to 99%, so when I returned home from a workout I unhappily found 30 minutes remaining. Sigh. Whatever happened to “it just works”?

All the people that were fanatically dedicated to the concept of not shipping user-hostile software retired or got laid off or quit.

The state of care and level of user compassion in modern macOS is at the nadir.

To the author of this piece: are you enlightened yet?

Have you decided yet to stop buying Apple hardware?

I made the leap last year. It’s been surprisingly pleasant. Everything we talk about where Apple hardware is untouchable and better than everyone else is outdated, if not outright propagandistic thoughts seeded Apple to its vast network of proponents.

Is my hardware as refined? No, not really. But it’s better, because it works like a normal PC without all the weird bespoke bullshit. Apple makes systems where it’s hard to see what’s going on and everything is put behind a curtain.

And really, all the innovation is outside of Apple.

Some examples: Look at the Zenbook Duo 2026, imagine carrying around a no-compromise dual OLED display laptop around with a processor with similar efficiency to the M5 with better graphics performance. And you get more storage space than a similarly priced MacBook Pro.

Look at the 2025-2026 Lenovo systems. They have haptic trackpads and top tier speakers, features that supposedly only Apple could accomplish.

Look at the Framework 13, a computer you can actually repair and upgrade on your own with first class Linux support, from a company that will actually engage with users rather than having a shroud of secrecy.

Look at the wide variety of laptops with Nvidia RTX 5000 series graphics, which Apple’s best and most pricey solutions can’t match for performance.

Where are the MacBook Pro systems with tandem OLED displays? Why is there still a notch in the middle of the screen especially when there is no Face ID? When is Apple going to refresh the MacBook Pro design that is now almost 5 years old?

Look at the Linux desktop, where the development experience is way less janky and compromised than macOS and you can run almost all Windows games after you’re done working, and you can actually customize your system rather than fighting with it. It also doesn’t just randomly get slower because Apple wants to fuck up the UI with Liquid Ass.

There’s never been a better time to leave Apple behind. Back in the days of the G4 and G5, Apple users dealt with worse processor performance and efficiency just to use a superior experience. Now macOS users are doing the opposite: using a terrible system with a terrible experience just to get the best shiniest hardware and the best chips, which isn’t even very much of an advantage anymore (hello panther lake).

I’m curious if anyone knows the reason it’s so strict about the port? It’s a weird thing. My best theory is maybe in DFU mode it skips HAL enumeration and just has a hardcoded link between that single port and the microcontroller that does DFU? It’s a stretch but that’s the main theory I have and would explain why they also sometimes had weird capability mismatches between ports on different sides.

Edit: according to ChatGPT that is basically the reason. That one port is connected to the SoC’s building PHY that’s guaranteed to be on without needing any firmware. Other ports are routed through other controllers and whatnot and those may require firmware. Also the DFU port is guaranteed to not need PD negotiation to turn on.

DFU could opportunistically try to load firmware and start those devices but it’s risky since the firmware may be what’s bricked and might itself break DFU so for simplicity it’s in an absolutely barebones mode that the CPU supports and is wired for directly.