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
Or at least that's how it reads to me. As for reasons, I don't know why anything that can boot from USB can't from DFU-enabled USB port, but maybe it's configured as a special non-USB debug connector while bootloader is executing.
This is what I'm contending. No, I don't think this is true. All he found was the upgrading macOS on the external disk, which as documented must not be on a DFU capable USB-C port, did not work when plugged into a port that was documented to not be DFU.
The source the author is referring to, Michael Tsai, indeed found that he had plugged his external disk into the DFU port. The author then (reasonably, but IMHO erroneously) deduced that his problem, also solved by changing ports, must thus have had the same cause. I say it may be confounding factors, and the only way to validate the wrong DFU port hypothesis is putting their mac in DFU mode and then running Recovery Assistant (from another machine) against it, on various ports.
Tangentially, it is infuriating that Apple would swap what the DFU port is across generations, as if it wasn't confusing enough.
Also...
> As for reasons, I don't know why anything that can boot from USB can't from DFU-enabled USB port, but maybe it's configured as a special non-USB debug connector while bootloader is executing.
My guess is it's because DFU requires the port to be in Device mode, whereas booting from a external disk requires the port to be in Host mode. Apple care about boot time, so perhaps they don't want to waste time in the boot process to check the port in Device mode for a few secs, then switch to Host mode to try external disk booting.
>This is what I'm contending. No, I don't think this is true
If you don't think it's true you're "contesting" it not "contending" it. To "contend" is to argue, so you would only use that if you were adopting the argument you quoted.
Fine, but a normal USB stick isn't a DFU capable USB *host*. DFU is a protocol for a *host* to update on a device. Unless you're trying to update the firmware of the USB stick the direction is wrong.
At most the DFU capable USB port on the Mac doesn't support booting of USB mass storage devices for some stupid reason.
The author just wants to apply system update, and it should "just work".
The DFU part is just a distraction, what happened to "just works", as they point out in the article.
We should not even _know_ anything about DFU unless we actually _are_ updating firmware.
I'm not sure that it uses standard DFU protocol. When I had to write firmware from Linux, I had to use some software specifically for Mac (idevicerestore) and I had the impression that it was super proprietary stuff.
> 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
And I guess because of the wide variety of third-party hardware macOS has to support, it's not practical to write a pre-flight check into the update process either.
> This is wrong, a discovery that took me about a half dozen attempts to update macOS on an external disk. I have a 16-inch MacBook Pro with an M4 chip, specifically an M4 Pro chip, and the DFU port seems to be the USB-C port on the right side of the Mac, not on the left side."
It appears that the author is directly contradicting your read.
Now the question is: what is left and what is right. For the user this most logically would be whats left and what's right when they look at the open display. For Apple it may be when you look at the top cover with the logo in proper direction. They have odd priorities like that. :D
> You don't present any alternative theory for the behavior, just assert that I'm wrong.
Not the GP, but it is easy to refute your theory. Just do a DFU with the port indicated by Apple and it works per Apple instructions. I have personally tested this and can attest it works as intended.
I don't think one logically needs to be burdened to come up with an alternative theory for why your macOS update process to be able to conclusively refute your implication of Apple docs about which port is DFU being wrong.
> it is easy to refute your theory. Just do a DFU with the port indicated by Apple
No, it's not easy. I just said, in the comment you replied to, "I'm not even sure that I have all the prerequisites on hand."
> I have personally tested this
On my Mac model?
To be clear, I'm saying that the doc is wrong about my specific, relatively new Mac model, which I bought a year ago. I'm not claiming that the doc is wrong about other, older Mac models.
I have tested DFU restore on multiple Mac models including MacBook Air {M1, M2, M3, M4}, MacBook Pros {M1 Pro, M1 Max, M3 Max, M4, M4 Max}, Mac mini {M1, M4}, Mac Studio {M1 Max, M3 Ultra} off the top of my head (at least a bunch of older Intel+T2). I am sure many other people would have noticed if the DFU port was marked incorrectly. You are simply too quick to conclude what could be a bug in macOS updater is necessarily tied to DFU port designation. Just as an example, I have a USB-C flash device that is so flaky that sometimes does not work with a port on one direction and connect/disconnect and flipping the direction works. There's just any number of possibilities aside from DFU.
I have an M4 Pro, so you have not tested with my specific model.
> I am sure many other people would have noticed if the DFU port was marked incorrectly.
Why? Again, I'm not generalizing to many Mac models. Apple's doc specifies a very limited exception: 14-inch MacBook Pro with M4 or M5 chip.
And among users of the limited exceptions, who would notice except the few who need to DFU or the few who have macOS installed on an external disk? That doesn't sound like so many to me.
> a bug in macOS updater
So vague as to be an unhelpful handwave.
> Just as an example, I have a USB-C flash device that is so flaky that sometimes does not work with a port on one direction and connect/disconnect and flipping the direction works.
This example is not applicable to my case. The external drive otherwise works perfectly. It's not flakey at all. And in fact it boots into macOS Sequoia just fine, and software update on the volume works fine for non-macOS updates, such as Safari. So again, you've given me zero alternative theories.
Moreover, the symptoms that Michael Tsai described in his case of using the DFU port are exactly the same as the symptoms that I experienced.
[EDIT:] I looked around, but unfortunately I don't appear to have the proper cable to perform a DFU test. In fact I usually need to use some damn dongle just to connect to USB-C.
> [EDIT:] I looked around, but unfortunately I don't appear to have the proper cable to perform a DFU test. In fact I usually need to use some damn dongle just to connect to USB-C.
FYI, USB-3.0 C-to-A dongle + USB-3.0 A-to-C cable definitely works (haven't tested USB 2.0). The C side of the cable needs to be plugged in to the machine being DFU'd not the host machine where the dongle goes.
I didn't have the same issues, but I wouldn't say "it just works".
I've dealt with this in the past two weeks, actually.
I had an M1 MBP that I needed to re-pave with Monterey. Yes, it's end-of-support, but it's also only 4 years old. And should run on that Mac.
So, first step, I make a USB installer, and run it. Great. Reboots, and says "FYI, this is an unsupported OS. You can install a newer OS instead, or run Monterey in "Reduced Security" mode." That was fine for me.
"Installation of Reduced Security mode failed." Nothing else. Eventually my understanding of this was because the machine had been upgraded previously all the way to Tahoe, that somewhere along the line some firmware or something in the EFI had been upgraded and was too new for Monterey.
So what then?
Hmm, more research. "Do an IPSW image restore via DFU", i.e. pave it with a largely installed image. Could work, might have the same issue, but I'm stuck right now, with a Mac I can't install anything on, a four year old $3,000 brick.
Alright, I have a Mac Studio. I get the IPSW image, and Apple Configurator. Connect the two as per Apple's instructions, and (different here to OP), the MBP does indeed show up in Configurator as being "not booted, DFU mode".
Apple's instructions, "Drag the IPSW image onto the DFU 'box' for the target Mac". No. It doesn't light up like it's accepting a drag and drop, and indeed it doesn't. Nor does it accept a "restore..." or similar from the Configurator menu options. There's nothing in Configurator that seems to allow you to image the MBP.
Off to ChatGPT, Reddit, etc., I go.
Much repeating of the same. However, ChatGPT pokes a little button. Near the very end of its answer, it says "Newer versions of macOS may have limitations on the age of the image they might restore. You may need a slightly older macOS to do this. Even an Intel MBP running Ventura could work."
As fortune has it, my fiance happens to still have her old i5 MBP with touchbar, and the latest version of Ventura...
Alright, I need Configurator on this laptop.
No, says the App Store, "You need macOS Sequoia to install Configurator".
I find someone who has helpfully zipped up an older version of Configurator that runs on Ventura, and in the end, it works.
But Apple's docs absolutely are incorrect/incomplete about Configurator, and DFU restores.
"You can use Restore... in the Configurator menu to select the software image". No, you can't, even leaving aside the "old/unsupported". It actually means restoring from a "backup" (presumably Time Machine, though it doesn't specify) and you can't select any file or image.
"Drag the image onto DFU". Doesn't work in that situation, no error, no "hey, you're doing the right thing but I can't do this", just acting like a fool trying to drag the image onto DFU only to have it bounce off.
Like I said, I didn't have the DFU port issues, but Apple's docs on how to make this happen were either non-existent, or incorrect about the process, or flat out told me I couldn't do it. But mostly non-existent and overly simplistic covering the most basic scenarios only - which I get for general support, but by the time you are "connect to a second mac in DFU mode and run Configurator" in their own words, we're way beyond simplistic "you can just install a newer macos" type "instructions".
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.
Not sure, maybe there are other ways to achieve that (instinctively, I think the attack surface is much larger in your solution as it relies on the correctness of recoveryOS, not just bootrom/iBoot), but DFU would be easiest/safest/fastest and less error-prone for me. My ritual is to just plug in another Mac running Apple Configurator to my newly arrived iOS/macOS device and restore the OS image (actually faster than using a USB disk to install macOS). I think your approach may validate the system disk, but not whether configuration in data partition is loading a separate key logger binary on boot.
The luxury of having a second Mac to DFU is useful, sure — but optional. Once you’ve got rescue working, you just boop the data partition and the system is in sealed-safe fresh start mode.
Well, the risk there is slightly higher as you are assuming rescue partition does not have an exploit planted? Empirically, we've had iOS jailbreaks that exploited higher level kernel, but not bootrom.
That said I do it because DFU has been just faster than having the system do "Internet Recovery" not strictly for security purposes.
FWIW, you do not need another Mac to DFU restore another. Any computer could do[1].
Well, I used to open with wiping the partition table from rescue terminal, when I couldn’t prove anything was sealed properly, which forces Network Recovery from the bootrom (and serves as a nice confirmation that it was wiped) — but now that the OS can get a secure attestation from the bootrom, I don’t stress quite so much about that. There are a lot of advantages to attestation in time savings!
The author followed the "all other MacBooks" case, but it appears that their Mac (a 16-inch model) also has it on the other side than the instructions claim.
I am reading the post again. It does appear the author is not fully aware what DFU is supposed to do. They are talking about "storage devices" in that context, which is a total misread--their interpretation of DFU seems to be something close to "default boot device."
The DFU port is definitely not the singular one on the right side of the device. The documentation debate is about which port on the left side of the device (closer or farther from MagSafe.)
> They are talking about "storage devices" in that context, which is a total misread
What misread are you talking about? I'm talking about storage devices because the documentation says you can't update macOS on an external storage device while it's connected to the DFU port.
> their interpretation of DFU seems to be something close to "default boot device."
No, that's not my interpretation. I have no idea where you're getting that from the blog post.
Fair enough. I now see the connection (i.e. separate from DFU process another doc excludes DFU designated port from participating in your process.) Regardless the documentation is 100% correct re which port is DFU port. If your process fails, it could be for any number of reasons only one of which has to do with using the DFU port, so it is not a logical implication to conclude the failure means DFU port is wrong.
You misunderstand what this is. You suggested in another comment that I test the theory by trying the DFU process, but that is not reductio ad absurdum.
Theory: "the DFU port seems to be the USB-C port on the right side of the Mac [p], not on the left side."
Reductio ad absurdum: "[p] port R is DFU => [q] we should be able to execute DFU process on port R (and not port L)" We execute DFU on port R and it fails [NOT q], therefore [NOT p], so the theory cannot be correct. QED
You can turn every empirical theory into a so-called "reductio ad absurdum" by phrasing the results of empirical tests as a premise in the argument, but that is itself totally absurd and a mockery of the logical idea.
It's not a mockery—that is precisely at the core of scientific method. Theory makes predictions (logical implications), and if you empirically find contradictory evidence, the theory is proven incorrect.
> Theory makes predictions (logical implications), and if you empirically find contradictory evidence, the theory is proven incorrect.
Of course. But again, that is not the form of argumentation known as reductio ad absurdum.
Reductio ad absurdum is not at the core of scientific method. Reductio ad absurdum is used for example in pure, nonempirical mathematics and geometry, and typically starts by assuming the opposite of the conclusion.
Ah yes the woke practice of the singular they, when gender doesn't matter or is ambiguous. Which a hundo-percent never existed before scary mean woke-ism.
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.).
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."
It's wild that we live in an era where computers are doing real-time ML inference and firmware updates over USB-C, but basic error reporting has regressed to "something happened, good luck"
DFU the protocol isn’t the issue — the ambiguity is around which physical port actually exposes DFU at boot, and that seems to vary by SoC variant (base vs Pro/Max), not just by chassis. The docs don’t make that distinction clear.
The fact that switching ports fixes the issue strongly suggests boot-ROM-level port routing differences. macOS wouldn’t have visibility there anyway, which explains the lack of diagnostics — but it also means the docs/UX are doing too much hand-waving.
This reads less like “DFU is broken” and more like a documentation gap that only shows up in recovery flows — exactly where precision matters most.
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.
> I would simply say: "Always use the same port for booting and installation." Which usually simplifies the process.
That would be even worse than not being able to update macOS on the DFU port. I'm supposed to remember which of 3 ports I originally used, forever??
> Maybe on another Mac/machine. When they change the machine
No, I did not use another machine.
The entire purpose of this install on an external disk was to take screenshots from my MacBook Pro. My other machine, a Mac mini, has a non-retina display, which is not good for that purpose, not to mention that the Mac mini already has multiple boot volumes, so I wouldn't need an external disk with that machine.
> That would be even worse than not being able to update macOS on the DFU port. I'm supposed to remember which of 3 ports I originally used, forever??
I simply use the port that is closest to the MagSafe. Haven't tried much with the M1 macs though, since because my M1Pro MBP was issued by the company and had lots of restrictions on it.
> 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.
Apple's been shipping user-hostile software for decades. I quit after they closed the gap in the wall that allowed me to add a song to my ipod without going through the monstrosity called iTunes.
The corporate culture shifted steadily at Apple following Jobs’ death. It was obviously a turning point for the company and while the change wasn’t overnight, in the ten years that followed, a lot of people moved on, because (obviously) Apple will never be Apple under Jobs ever again.
Because many of them had been with the company a long time (and were thus old), they were replaced by mostly younger people who had less experience with what makes Apple Apple.
In my personal opinion, the soul went out of the company. It wasn’t immediately when Jobs died - to his credit it took more than a decade for the momentum of his vision to die.
Today, Apple is just another multinational, nickel and diming their customer base for services revenue, cooperating with the totalitarian surveillance state (not that they have much choice in the police states of the PRC and USA in which they operate/can’t fight city hall), shipping incrementially improved products (and incrementally worse software), and misleading their customers with clever marketing. It’s just business. It used to be something else entirely.
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.
I may be able to resolve this, having hacked a bunch on M1N1 and such - the DFU port is going through a microcontroller with firmware.
That is why, for example, it can properly process USB-PD messages that contain vendor defined message codes, even prior to any form of boot, as long as it has any source of power.
The firmware on the USB controller is processing that.
This is how VDMTool works to be able to mux debug (and do other things) even with the machine otherwise off.
> Doesn't that linked webarchive page say specifically that the ACE is a "Apple/TI co-designed USB Type-C Port Controller" If that isn't a "USB Controller" what do you mean when you say "USB Controller"?
"USB controller" in common parlance means a USB host controller, the hardware that actually controls the USB signals and interfaces with the host CPU(s). They are required no matter if the physical port is type A, B, C, ...
A "port controller" is something completely different, but still related to the "USB type C port" specification. It's a piece of logic (in this case in a separate IC) that handles things like negotiating PD, as well as which protocol(s) will be used over the high speed lanes etc. See the section about pin usage in different modes: https://en.wikipedia.org/wiki/USB-C
comex's comment is inaccurate with respect to the commonly understood meaning of "USB controller" - while that port does have the CC lines going to ACE, the actual USB data lines go to the Apple SoC directly.
This is contrasted with a different design where the USB data lines could go to a standalone IC, and that IC is connected to the Apple SoC via PCIe for example. DFU is significantly more complicated in this type of design because it requires bootstrapping and interaction with this external component.
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.
The source the author is referring to, Michael Tsai, indeed found that he had plugged his external disk into the DFU port. The author then (reasonably, but IMHO erroneously) deduced that his problem, also solved by changing ports, must thus have had the same cause. I say it may be confounding factors, and the only way to validate the wrong DFU port hypothesis is putting their mac in DFU mode and then running Recovery Assistant (from another machine) against it, on various ports.
Tangentially, it is infuriating that Apple would swap what the DFU port is across generations, as if it wasn't confusing enough.
Also...
> As for reasons, I don't know why anything that can boot from USB can't from DFU-enabled USB port, but maybe it's configured as a special non-USB debug connector while bootloader is executing.
My guess is it's because DFU requires the port to be in Device mode, whereas booting from a external disk requires the port to be in Host mode. Apple care about boot time, so perhaps they don't want to waste time in the boot process to check the port in Device mode for a few secs, then switch to Host mode to try external disk booting.
>This is what I'm contending. No, I don't think this is true
If you don't think it's true you're "contesting" it not "contending" it. To "contend" is to argue, so you would only use that if you were adopting the argument you quoted.
Fine, but a normal USB stick isn't a DFU capable USB *host*. DFU is a protocol for a *host* to update on a device. Unless you're trying to update the firmware of the USB stick the direction is wrong.
At most the DFU capable USB port on the Mac doesn't support booting of USB mass storage devices for some stupid reason.
The author just wants to apply system update, and it should "just work". The DFU part is just a distraction, what happened to "just works", as they point out in the article. We should not even _know_ anything about DFU unless we actually _are_ updating firmware.
I'm not sure that it uses standard DFU protocol. When I had to write firmware from Linux, I had to use some software specifically for Mac (idevicerestore) and I had the impression that it was super proprietary stuff.
> 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
And I guess because of the wide variety of third-party hardware macOS has to support, it's not practical to write a pre-flight check into the update process either.
The author was not saying the document labeled wrong port as DFU port.
He is saying the documented _behaviour_ of DFU port is wrong (or, at least, in complete.)
The post says:
> This is wrong, a discovery that took me about a half dozen attempts to update macOS on an external disk. I have a 16-inch MacBook Pro with an M4 chip, specifically an M4 Pro chip, and the DFU port seems to be the USB-C port on the right side of the Mac, not on the left side."
It appears that the author is directly contradicting your read.
Now the question is: what is left and what is right. For the user this most logically would be whats left and what's right when they look at the open display. For Apple it may be when you look at the top cover with the logo in proper direction. They have odd priorities like that. :D
They say it's the left and right ports when facing the left side of the Mac.
> It appears that the author is directly contradicting your read.
Correct.
> The author did not test the DFU flow
I'd rather not. I'm not even sure that I have all the prerequisites on hand.
> I'm not sure why they're blaming the DFU port documentation.
1) The documentation says that macOS cannot be updated on the DFU port.
2) Switching ports allowed my macOS update to succeed after repeated failures on one port.
3) The 14-inch MacBook Pro with M4 chip is documented as different from all other models, but strangely, not the 16-inch MacBook Pro with M4 chip.
You don't present any alternative theory for the behavior, just assert that I'm wrong.
> You don't present any alternative theory for the behavior, just assert that I'm wrong.
Not the GP, but it is easy to refute your theory. Just do a DFU with the port indicated by Apple and it works per Apple instructions. I have personally tested this and can attest it works as intended.
I don't think one logically needs to be burdened to come up with an alternative theory for why your macOS update process to be able to conclusively refute your implication of Apple docs about which port is DFU being wrong.
> it is easy to refute your theory. Just do a DFU with the port indicated by Apple
No, it's not easy. I just said, in the comment you replied to, "I'm not even sure that I have all the prerequisites on hand."
> I have personally tested this
On my Mac model?
To be clear, I'm saying that the doc is wrong about my specific, relatively new Mac model, which I bought a year ago. I'm not claiming that the doc is wrong about other, older Mac models.
I have tested DFU restore on multiple Mac models including MacBook Air {M1, M2, M3, M4}, MacBook Pros {M1 Pro, M1 Max, M3 Max, M4, M4 Max}, Mac mini {M1, M4}, Mac Studio {M1 Max, M3 Ultra} off the top of my head (at least a bunch of older Intel+T2). I am sure many other people would have noticed if the DFU port was marked incorrectly. You are simply too quick to conclude what could be a bug in macOS updater is necessarily tied to DFU port designation. Just as an example, I have a USB-C flash device that is so flaky that sometimes does not work with a port on one direction and connect/disconnect and flipping the direction works. There's just any number of possibilities aside from DFU.
> MacBook Pros {M1 Pro, M1 Max, M3 Max, M4, M4 Max}
I have an M4 Pro, so you have not tested with my specific model.
> I am sure many other people would have noticed if the DFU port was marked incorrectly.
Why? Again, I'm not generalizing to many Mac models. Apple's doc specifies a very limited exception: 14-inch MacBook Pro with M4 or M5 chip.
And among users of the limited exceptions, who would notice except the few who need to DFU or the few who have macOS installed on an external disk? That doesn't sound like so many to me.
> a bug in macOS updater
So vague as to be an unhelpful handwave.
> Just as an example, I have a USB-C flash device that is so flaky that sometimes does not work with a port on one direction and connect/disconnect and flipping the direction works.
This example is not applicable to my case. The external drive otherwise works perfectly. It's not flakey at all. And in fact it boots into macOS Sequoia just fine, and software update on the volume works fine for non-macOS updates, such as Safari. So again, you've given me zero alternative theories.
Moreover, the symptoms that Michael Tsai described in his case of using the DFU port are exactly the same as the symptoms that I experienced.
[EDIT:] I looked around, but unfortunately I don't appear to have the proper cable to perform a DFU test. In fact I usually need to use some damn dongle just to connect to USB-C.
> [EDIT:] I looked around, but unfortunately I don't appear to have the proper cable to perform a DFU test. In fact I usually need to use some damn dongle just to connect to USB-C.
FYI, USB-3.0 C-to-A dongle + USB-3.0 A-to-C cable definitely works (haven't tested USB 2.0). The C side of the cable needs to be plugged in to the machine being DFU'd not the host machine where the dongle goes.
I didn't have the same issues, but I wouldn't say "it just works".
I've dealt with this in the past two weeks, actually.
I had an M1 MBP that I needed to re-pave with Monterey. Yes, it's end-of-support, but it's also only 4 years old. And should run on that Mac.
So, first step, I make a USB installer, and run it. Great. Reboots, and says "FYI, this is an unsupported OS. You can install a newer OS instead, or run Monterey in "Reduced Security" mode." That was fine for me.
"Installation of Reduced Security mode failed." Nothing else. Eventually my understanding of this was because the machine had been upgraded previously all the way to Tahoe, that somewhere along the line some firmware or something in the EFI had been upgraded and was too new for Monterey.
So what then?
Hmm, more research. "Do an IPSW image restore via DFU", i.e. pave it with a largely installed image. Could work, might have the same issue, but I'm stuck right now, with a Mac I can't install anything on, a four year old $3,000 brick.
Alright, I have a Mac Studio. I get the IPSW image, and Apple Configurator. Connect the two as per Apple's instructions, and (different here to OP), the MBP does indeed show up in Configurator as being "not booted, DFU mode".
Apple's instructions, "Drag the IPSW image onto the DFU 'box' for the target Mac". No. It doesn't light up like it's accepting a drag and drop, and indeed it doesn't. Nor does it accept a "restore..." or similar from the Configurator menu options. There's nothing in Configurator that seems to allow you to image the MBP.
Off to ChatGPT, Reddit, etc., I go.
Much repeating of the same. However, ChatGPT pokes a little button. Near the very end of its answer, it says "Newer versions of macOS may have limitations on the age of the image they might restore. You may need a slightly older macOS to do this. Even an Intel MBP running Ventura could work."
As fortune has it, my fiance happens to still have her old i5 MBP with touchbar, and the latest version of Ventura...
Alright, I need Configurator on this laptop.
No, says the App Store, "You need macOS Sequoia to install Configurator".
I find someone who has helpfully zipped up an older version of Configurator that runs on Ventura, and in the end, it works.
But Apple's docs absolutely are incorrect/incomplete about Configurator, and DFU restores.
"You can use Restore... in the Configurator menu to select the software image". No, you can't, even leaving aside the "old/unsupported". It actually means restoring from a "backup" (presumably Time Machine, though it doesn't specify) and you can't select any file or image.
"Drag the image onto DFU". Doesn't work in that situation, no error, no "hey, you're doing the right thing but I can't do this", just acting like a fool trying to drag the image onto DFU only to have it bounce off.
Like I said, I didn't have the DFU port issues, but Apple's docs on how to make this happen were either non-existent, or incorrect about the process, or flat out told me I couldn't do it. But mostly non-existent and overly simplistic covering the most basic scenarios only - which I get for general support, but by the time you are "connect to a second mac in DFU mode and run Configurator" in their own words, we're way beyond simplistic "you can just install a newer macos" type "instructions".
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.
Isn't the OS untampered so long as booting into rescue mode > startup security shows it to be in sealed/verified mode?
Not sure, maybe there are other ways to achieve that (instinctively, I think the attack surface is much larger in your solution as it relies on the correctness of recoveryOS, not just bootrom/iBoot), but DFU would be easiest/safest/fastest and less error-prone for me. My ritual is to just plug in another Mac running Apple Configurator to my newly arrived iOS/macOS device and restore the OS image (actually faster than using a USB disk to install macOS). I think your approach may validate the system disk, but not whether configuration in data partition is loading a separate key logger binary on boot.
The luxury of having a second Mac to DFU is useful, sure — but optional. Once you’ve got rescue working, you just boop the data partition and the system is in sealed-safe fresh start mode.
Well, the risk there is slightly higher as you are assuming rescue partition does not have an exploit planted? Empirically, we've had iOS jailbreaks that exploited higher level kernel, but not bootrom.
That said I do it because DFU has been just faster than having the system do "Internet Recovery" not strictly for security purposes.
FWIW, you do not need another Mac to DFU restore another. Any computer could do[1].
[1]: https://github.com/libimobiledevice/idevicerestore
Well, I used to open with wiping the partition table from rescue terminal, when I couldn’t prove anything was sealed properly, which forces Network Recovery from the bootrom (and serves as a nice confirmation that it was wiped) — but now that the OS can get a secure attestation from the bootrom, I don’t stress quite so much about that. There are a lot of advantages to attestation in time savings!
The author followed the "all other MacBooks" case, but it appears that their Mac (a 16-inch model) also has it on the other side than the instructions claim.
I am reading the post again. It does appear the author is not fully aware what DFU is supposed to do. They are talking about "storage devices" in that context, which is a total misread--their interpretation of DFU seems to be something close to "default boot device."
The DFU port is definitely not the singular one on the right side of the device. The documentation debate is about which port on the left side of the device (closer or farther from MagSafe.)
> They are talking about "storage devices" in that context, which is a total misread
What misread are you talking about? I'm talking about storage devices because the documentation says you can't update macOS on an external storage device while it's connected to the DFU port.
> their interpretation of DFU seems to be something close to "default boot device."
No, that's not my interpretation. I have no idea where you're getting that from the blog post.
Fair enough. I now see the connection (i.e. separate from DFU process another doc excludes DFU designated port from participating in your process.) Regardless the documentation is 100% correct re which port is DFU port. If your process fails, it could be for any number of reasons only one of which has to do with using the DFU port, so it is not a logical implication to conclude the failure means DFU port is wrong.
> it could be for any number of reasons only one of which has to do with using the DFU port
Any number? How about naming them. Name one.
People in the comments here claim I'm wrong but totally hand-wave away my issue.
One can logically disprove a theory without providing an alternative theory: reductio ad absurdum.
> One can logically disprove a theory
You haven't done so.
> reductio ad absurdum
You misunderstand what this is. You suggested in another comment that I test the theory by trying the DFU process, but that is not reductio ad absurdum.
> You haven't done so.
Theory: "the DFU port seems to be the USB-C port on the right side of the Mac [p], not on the left side."
Reductio ad absurdum: "[p] port R is DFU => [q] we should be able to execute DFU process on port R (and not port L)" We execute DFU on port R and it fails [NOT q], therefore [NOT p], so the theory cannot be correct. QED
You can turn every empirical theory into a so-called "reductio ad absurdum" by phrasing the results of empirical tests as a premise in the argument, but that is itself totally absurd and a mockery of the logical idea.
It's not a mockery—that is precisely at the core of scientific method. Theory makes predictions (logical implications), and if you empirically find contradictory evidence, the theory is proven incorrect.
> Theory makes predictions (logical implications), and if you empirically find contradictory evidence, the theory is proven incorrect.
Of course. But again, that is not the form of argumentation known as reductio ad absurdum.
Reductio ad absurdum is not at the core of scientific method. Reductio ad absurdum is used for example in pure, nonempirical mathematics and geometry, and typically starts by assuming the opposite of the conclusion.
Genuinely curious — did you use an LLM to write this post; or do you have this tone naturally?
Love that this post starts with "genuinely curious" (a Claude-ism.)
No LLM entirely organic. (If you are talking about referring to the author as "they," that is impact to my head from working at woke workplaces.)
I can't really put my finger what (falsely!) tipped me off here.
I think the short, single clause, internal-monologue-ish sentences is what did it?
> I am reading the post again. It does appear the author is not fully aware what DFU is supposed to do.
That especially came off like an LLM being called out on being wrong about something?
Ah yes the woke practice of the singular they, when gender doesn't matter or is ambiguous. Which a hundo-percent never existed before scary mean woke-ism.
> it does not appear the root cause is which port is DFU, but a misunderstanding of the DFU process by the blogpost.
The blog post does not even discuss the DFU process.
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.
Installing from an external disk has nothing to do with DFU. It's not involved.
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."
It's wild that we live in an era where computers are doing real-time ML inference and firmware updates over USB-C, but basic error reporting has regressed to "something happened, good luck"
Feels like a few things are getting conflated.
DFU the protocol isn’t the issue — the ambiguity is around which physical port actually exposes DFU at boot, and that seems to vary by SoC variant (base vs Pro/Max), not just by chassis. The docs don’t make that distinction clear.
The fact that switching ports fixes the issue strongly suggests boot-ROM-level port routing differences. macOS wouldn’t have visibility there anyway, which explains the lack of diagnostics — but it also means the docs/UX are doing too much hand-waving.
This reads less like “DFU is broken” and more like a documentation gap that only shows up in recovery flows — exactly where precision matters most.
> Feels like a few things are getting conflated.
By whom?
> DFU the protocol isn’t the issue
I never said it was.
> the ambiguity is around which physical port actually exposes DFU at boot
Yes.
> This reads less like “DFU is broken”
I never said that.
> and more like a documentation gap
The title literally contains "documentation is wrong".
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.
> I would simply say: "Always use the same port for booting and installation." Which usually simplifies the process.
That would be even worse than not being able to update macOS on the DFU port. I'm supposed to remember which of 3 ports I originally used, forever??
> Maybe on another Mac/machine. When they change the machine
No, I did not use another machine.
The entire purpose of this install on an external disk was to take screenshots from my MacBook Pro. My other machine, a Mac mini, has a non-retina display, which is not good for that purpose, not to mention that the Mac mini already has multiple boot volumes, so I wouldn't need an external disk with that machine.
> That would be even worse than not being able to update macOS on the DFU port. I'm supposed to remember which of 3 ports I originally used, forever??
I simply use the port that is closest to the MagSafe. Haven't tried much with the M1 macs though, since because my M1Pro MBP was issued by the company and had lots of restrictions on it.
> I simply use the port that is closest to the MagSafe.
According to Apple, that's actually the DFU port.
In any case, Apple's docs don't say that you always have to use the same port with an external drive.
I believe the docs are just a bit unclear.
Your laptop does not have a standard M4 Chip it has an M4 Pro chip.
The 14in MacBook Pro comes/came with 3 chips types M4, M4 Pro, M4 Max
The model they are referencing is the base M4 and M5 chips - not the Pro or Max chips types which use the other port.
All documentation is wrong, well, nearly all!
This feels like a perfect example of Apple's modern "it just works… until it very much doesn't"
> 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.
Apple's been shipping user-hostile software for decades. I quit after they closed the gap in the wall that allowed me to add a song to my ipod without going through the monstrosity called iTunes.
I’d like to know more about that! Why did they quit? Who replaced them?
The corporate culture shifted steadily at Apple following Jobs’ death. It was obviously a turning point for the company and while the change wasn’t overnight, in the ten years that followed, a lot of people moved on, because (obviously) Apple will never be Apple under Jobs ever again.
Because many of them had been with the company a long time (and were thus old), they were replaced by mostly younger people who had less experience with what makes Apple Apple.
In my personal opinion, the soul went out of the company. It wasn’t immediately when Jobs died - to his credit it took more than a decade for the momentum of his vision to die.
Today, Apple is just another multinational, nickel and diming their customer base for services revenue, cooperating with the totalitarian surveillance state (not that they have much choice in the police states of the PRC and USA in which they operate/can’t fight city hall), shipping incrementially improved products (and incrementally worse software), and misleading their customers with clever marketing. It’s just business. It used to be something else entirely.
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.
ChatGPT is wrong. The DFU port does go through a USB controller with firmware. [1]
[1] https://asahilinux.org/docs/hw/soc/usb-pd/
> ChatGPT is wrong. The DFU port does go through a USB controller with firmware. [1]
> [1] https://asahilinux.org/docs/hw/soc/usb-pd/
What in your linked page made you conclude this? Your link references https://web.archive.org/web/20211023034503/https://blog.t801..., which clearly states that ACE is a port controller - this is not the same as a "USB controller".
I may be able to resolve this, having hacked a bunch on M1N1 and such - the DFU port is going through a microcontroller with firmware.
That is why, for example, it can properly process USB-PD messages that contain vendor defined message codes, even prior to any form of boot, as long as it has any source of power.
The firmware on the USB controller is processing that.
This is how VDMTool works to be able to mux debug (and do other things) even with the machine otherwise off.
Then why is there only one port capable of DFU?
See my response to tpmoney - not all signals in the DFU port go to the port controller.
Doesn't that linked webarchive page say specifically that the ACE is a "Apple/TI co-designed USB Type-C Port Controller"
If that isn't a "USB Controller" what do you mean when you say "USB Controller"?
> Doesn't that linked webarchive page say specifically that the ACE is a "Apple/TI co-designed USB Type-C Port Controller" If that isn't a "USB Controller" what do you mean when you say "USB Controller"? "USB controller" in common parlance means a USB host controller, the hardware that actually controls the USB signals and interfaces with the host CPU(s). They are required no matter if the physical port is type A, B, C, ... A "port controller" is something completely different, but still related to the "USB type C port" specification. It's a piece of logic (in this case in a separate IC) that handles things like negotiating PD, as well as which protocol(s) will be used over the high speed lanes etc. See the section about pin usage in different modes: https://en.wikipedia.org/wiki/USB-C comex's comment is inaccurate with respect to the commonly understood meaning of "USB controller" - while that port does have the CC lines going to ACE, the actual USB data lines go to the Apple SoC directly. This is contrasted with a different design where the USB data lines could go to a standalone IC, and that IC is connected to the Apple SoC via PCIe for example. DFU is significantly more complicated in this type of design because it requires bootstrapping and interaction with this external component.