macOS 26 Tahoe Won’t Install on the M3 Ultra Mac Studio

Article Comments
1

Originally published at: macOS 26 Tahoe Won’t Install on the M3 Ultra Mac Studio - TidBITS

Thanks to our old friend Ken Gruberman, who wrote on TidBITS Talk in response to “When Should You Upgrade to Apple’s OS 26 Releases?” (15 September 2025):

If you have an M3 Ultra Mac Studio, like me, the answer is NEVER. That’s because macOS 26 Tahoe WILL NOT INSTALL on these machines; you can’t update the existing system nor install it onto an external drive.

Others are also reporting the issue on the Apple Support Community, so it’s not an isolated problem. While some Apple support reps may not yet be aware of the issue, the growing number of reports suggests that Apple’s engineers are working on a fix. In the meantime, M3 Ultra Mac Studio users should either stay on their current version of macOS or upgrade to macOS 15.7 Sequoia for the latest security fixes. Given the high-end nature of the affected machines and the embarrassing nature of the lapse, I expect Apple to address this issue quickly.

2

This says NOTHING GOOD about Apple’s software QA.

1 Like
3

It appears that if you upgrade to macOS 15.7 and then try to upgrade to macOS 26 you will encounter this issue on the M3 Ultra Mac Studio.

If you upgrad from an earlier version of Sequoia the problem does not occur.

1 Like
4

I do not have an M3 Ultra Mac Studio, but I’m curious as to whether this anomaly happens only when one does an upgrade from OS 15.7 to OS 26.0. Also, what happens if one does a clean, fresh installation of Tahoe?

As it is, whenever I move from one Mac OS to another, I always do a clean, fresh installation of the new Mac OS on an “empty” Mac. This has always been successful for me, without any problems or issues.

5

What’s even the point of beta, public beta, and RC when Apple and their “dev” community can’t spot something as obvious as this on their most recent fancy kit? It’s outright embarrassing. Their whole software QA/QC has just been a cluster.

4 Likes
6

If the reports I’m seeing are true, it happens only when the Mac Studio has macOS 15.7 installed. 15.7 was released the same day as Tahoe’s official (non-beta) release. So the opportunity for testing this specific configuration (M3 Ultra Mac Studio, update to 15.7, then upgrade to Tahoe) would have been narrow.

How many beta testers are likely to install a beta that’s essentially just a security update, just to make sure that the RC of the new OS will install correctly on it? And how many of them are going to do this testing on that specific model?

Apple’s ability to do in-house testing is not infinite. A bug that affects only a specific model when upgrading the OS in a very specific manner is an easy one to miss. As bugs go, this one may seem major, but its consequences are minor: the upgrade simply doesn’t install. No data loss, no damage to the existing OS, just an inability to install the upgrade right away. It’s embarrassing, yes, but not dangerous, therefore not severe.

Remember: it doesn’t matter how much beta testing is done—the release will exhibit bugs. Only the shortest and most basic of programs (we’re talking “Hello World” level) can be perfect. Bugs Happen.

There will always be particular configurations that can trigger a bug that weren’t tested fully, because the number of possible configurations is large enough to be considered functionally infinite. The number of users who will update to an official release on Day One is at least a magnitude greater than the number that will beta test that release, giving a magnitude greater chance of someone having a configuration that triggers a bug.

Sorry for the rant, but it gets frustrating that every single time Apple releases a new major OS upgrade, and an embarrassing bug manifests in some specific configuration, people keep complaining, “Why did they bother to beta test if bugs will still get through?”

You want embarrassing bugs? Microsoft continually, repeatedly, pushes out Windows updates that cause downtime, data loss, and even bricking, sometimes extremely widespread. These aren’t the major releases, either; these are regular, incremental updates. Now that’s embarrassing.

The quality of software QA/QC isn’t whether the software comes out bug-free—it’s how many bugs were caught and fixed before you ever heard about them. It’s how quickly major bugs get fixed after they manifest. (Sadly, minor bugs with merely annoying consequences simply aren’t a priority for any FAANG-level tech megacorp. Apple is not even close to unique in that regard.)

7 Likes
7

The quality of software QA/QC isn’t whether the software comes out bug-free—it’s how many bugs were caught and fixed before you ever heard about them.

I disagree with this. It should be the goal of developers to produce bug-free software, and the goal of QA to verify that. It should NOT BE the goal of developers to toss bug-ridden software over to QA and hope QA finds them before release. We must stop accepting the premise that “bugs are acceptable.” Having worked in high confidence systems, it’s a combination of technologies, processes, and individual and organizational commitment.

“Better than Microsoft” should not be the quality we accept!

8

But not within Apple, prior to their release.

9

Nah, what’s really annoying is that they release an update that won’t even install and this not on some obscure decades old config with specific peripherals or on a specific type of network connection, but on their latest and greatest fancy schmancy $4k+ workstation in a bare vanilla setup.

What’s also annoying is that no matter how large of an eff up, there will always be a few that manage to show up to make up preposterous excuses, even if as outlandishly irrelevant as, MS would have done worse. Let’s knock that off right away. What I’d really want to hear is how Apple would need to change its processes to make sure something as obvious as this in a case as trivial as this just cannot happen again. (along with perhaps who got fired)

Edit: I’ll add that the whole there will always be some bugs is a complete straw man. Of course there will be! I have a whole list of reported and still not fixed bugs right here. But that’s entirely beside the point. Nobody ever asked for no bugs. What’s entirely reasonable (if not imperative), however, is to require proper testing is in place so that it’s ensured that an installer can even install in the first place. But apparently, asking that of our favorite fruit company already amounts to sacrilege for some. Oh well then.

3 Likes
10

I agree generally that bugs are not acceptable, nor should developers consider bugs to be acceptable. However, because of the nature of software development, expecting totally bug-free software is simply not realistic.

Developers need to have an attitude of minimizing the amount of bugs introduced, PRIOR TO RELEASE, which generally, they do not have at this time, in this US economy. The problem is, the longer a bug resides in a released product, the more expensive it is to remove. Prevention is actually the cheapest form of bug removal.

11

Nobody ever asked for “totally bug-free software”. Nobody.

12

I ask for it. All the time.

But I’m not so naïve as to believe I’ll ever get it.

2 Likes
13

Nobody ever asked for “totally bug-free software”. Nobody.

That is complete bovine effluent. That’s the expectation in safety critical systems, like aircraft. Now the specified reliability for avionics is “the chance of a failure is 10^-9” (yeah, 1/1,000,000,000) But no known bug is acceptable, and the obvious expectation is ‘no bug at all’. That requires a huge investment in development techniques and verification techniques. I worked on some technology that went into B-777. Boeing 777 - Wikipedia NO SOFTWARE accidents on this aircraft (so far.) There are 1767 aircraft delivered, starting in 1995. I don’t know how many flight hours for that aircraft family, but particularly given this is a transcontinental aircraft, it would be A Big Number.

Praxis (now Altran-Praxis, Altran Praxis - Wikipedia ) developed several safety-critical/mission-critical systems using formal verification. One was an automated helicopter landing autopilot, another was the master ‘money server’ for a British financial company. For that latter system, it came with a formal warranty “This software has no bugs.” They used this language: SPARK (programming language) - Wikipedia

I’ve been calling for software vendor liability (and limits on same, as is done for other professional engineering liability) for almost 40 years. And when I left the Canadian Air Traffic Control project, I told my replacement, “If you find a bug/problem in my code, let me know and I’ll help you fix it for free.” She never called. (And the one component was the second-most complex piece of code I ever wrote, a lot of it was highly compiler-dependent to meet a really tough performance requirement.)

1 Like
14

10 posts were split to a new topic: Display oddities with a new Mac mini and old display—DVI? HDMI?

15

There’s a very big difference between desktop computer system software and embedded software that is designed to run on one very specific hardware platform (like a 777) and will never be run on anything else (except, probably for a 777 simulator).

Some other Boeing plane might run a variation on the software, but I assume they will create a new project with a separate development process. They won’t be developing one software package for multiple types of aircraft.

In the consumer space, the problem is much more difficult. Even in a somewhat closed hardware ecosystem like a Mac, there are dozens of different computer models and configurations. And there are going to be thousands of different kinds of deployments (connected peripherals, installed software, networking environment). This makes it far more difficult to find and fix every bug.

In the PC world (e.g. Windows and Linux), the problem is even worse, because you’ve got millions, if not billions, of hardware configuations. (multiple models of multiple generations of CPUs from Intel and AMD, multiple motherboards with different built-in peripherals, and hundreds of different kinds of internally-connected peripherals). Plus the external peripherals, software and networking environments that Apple has to deal with.

So no, I can not possibly agree with your premise that zero-bug products are possible. There are just too many uncontrollable factors in this environment, which you don’t get for embedded software.

That having been said, it is still inexcusable that macOS 26 can’t install over 15.7 on any currently-shipping Mac hardware.

I can understand a bug that results from an obscure hardware or software configuration. There’s no excuse for one that manifests on a stock system with a default configuration without any user interaction.

Weird. I’d love to know what the problem is.

I’m also using an old DVI display (a Dell 2405FPW - 1200p featuring DVI, VGA, composite, component and S-Video inputs) and it’s been working fine on my 2024 M4 mini using an Apple HDMI-DVI adapter (the one that was bundled with my old 2011 Mac mini).

On my 2018 mini, there were always problems with the initial video sync. After a power-cycle or something that resets the chips (like a firmware upgrade), I’d get a picture, but shifted with a magenta line along one edge. A hot-plug of the monitor (remove and reconnect the HDMI adapter) would produce a good picture, which would last across reboots until the next power-cycle/chip reset.

On my 2024 M4 mini, I don’t see this. I get a proper picture every time. After a lot of uptime, I’ve noticed the image shifted one pixel to the right, with a white stripe in the leftmost column). Hot-plugging the HDMI connector fixes it. So the DVI integration is still not perfect, but I’m definitely not seeing what you’re seeing.

I wonder if you’d have the same problem using a cheap USB-C DVI adapter.

16

Excellent post! But your points just re-enforce what has always been the case: NEVER Install the initial version of a new Mac OS. I have yet to see a bug free new version of a Mac OS in quite some time. And going forward, still wait for at least OS 26.2.

As for testing upgrading OS 15.7 to OS 26.0, like you said, 1) not enough time to do it, and 2) Apple cannot test this on every model. This is a weird one though, and from what I remember, never seen something like this before.

This gives me all the more reason to follow my standard process: 1) make a SuperDuper! (SD) backup for each of my Macs to external SSDs, 2) prepare the OS 26.x flash drive, 3) use Disk Utility to completely wipe each of my Macs, 4) do a clean, fresh installation of OS 26.x via the flash drive, and 5) migrate all my “stuff” from the just completed SD backup. Always works flawlessly for me, and the result is a smooth, clean system on each of my Macs.

17

I expect that Apple has created a lot of special chip features, because they can and it allows faster speeds. Only problem is that it means special code for the access routines and eventually they made a mistake.