2013 Mac Pro 6.1 Revival Project (by a Linux newbie)

[iMmARKAyLWARD]

I had this great idea that I was going to revive my Mac Pro 6.1 and use it again as my daily driver. After completing my feature film, it quickly became abandoned, the Mac OS was already near the maximum release, held back by Davinci Resolves quirkiness and risk of not being able to control my feature films project file. So rather than risk issues, I stopped updating anything in order to safely release my film.

Now that a few years have passed, I see Davinci Resolve for example is up to Version 20+ and I am stuck back at 17. The Mac OS has on more update/upgrade available but then no longer supported. So Linux became my fancy.

What if I could install Linux and bring Davinci Resolve all the way up to Version 20+ and keep this machine alive?

So here is what I did and the summary so far of the challenges I faced.

Knowing very little about linux and quickly having my eyes gloss over as endless technical jargon and command line codes were being quoted, ChatGPT was my only friend.
BUT WAIT, Sure this forum and others were indispensable, but let's face it. The extensive troubleshooting required was not going to work for me over forum chats.
So here is a summary of my work that took 4, 2-4hr sessions over the last weekend.

 

[iMmARKAyLWARD]

Workstation Intent and Hardware Platform

This project began with a very specific objective: to build a stable, high-performance Linux workstation based on the Mac Pro 6,1 (Late 2013 “Trash Can”) platform. The target use case was professional daily production work, primarily:

• Video editing and grading (DaVinci Resolve)
• Audio production (Audacity and related tools)
• Image manipulation (GIMP)
• General content creation
• Multi-drive storage workflows

The hardware platform included:

• CPU: Intel Xeon E5-1650 v2 (6 cores / 12 threads)
• Memory: 64GB ECC RAM
• Storage: 1TB NVMe SSD (primary OS drive)
• GPU: Dual AMD FirePro D700 (Tahiti-based, essentially Radeon HD 7970 class)
• External Storage: Pegasus2 R4 (4-bay Thunderbolt RAID enclosure)

Performance expectations were:

1. Full hardware GPU acceleration (OpenGL/OpenCL)
2. Stable dual-GPU initialization
3. Reliable NVMe performance
4. Proper Thunderbolt storage mounting
5. Long-term LTS stability over bleeding-edge experimentation

It was intended to function as it did while under Apple support.

I initially began with elementary OS, but after much help from ChatGPT managing stability and kernel-level GPU bring-up issues, we restart with Ubuntu 24.04 LTS for its broader support base, longer lifecycle, and stronger documentation ecosystem.

 

[iMmARKAyLWARD]

Kernel Challenges and Dual D700 GPU Bring-Up

Once I was able to install Ubuntu onto the NVMe (after having boot-loop failure with elementaryOS), the most technically demanding portion of the build involved configuring for the dual AMD FirePro D700 GPUs.

Initial Problem

On the default kernel 6.17 (or 14 I forget), the Mac Pro 6,1 exhibited:

• Black screen during boot
• Inconsistent GPU initialization
• Display manager failures
• Occasional complete graphical stack collapse

The system would sometimes boot but fail to properly initialize both GPUs under amdgpu. This required systematic troubleshooting, that thanks to ChatGPT, I was tagging along and learning what best I could at entering Command line codes and managing GRUB menus.

The Role of nomodeset

Thanks to this forum and the posted guidance …

https://forums.macrumors.com/threads/linux-on-a-2013-mac-pro

… I implemented nomodeset in GRUB as a controlled and temporary fallback mechanism. This allowed me to prevented immediate GPU kernel mode setting, allowed safe recovery when amdgpu failed and enabled boot access for further diagnostics. Temporary because using nomodeset disables proper GPU acceleration, forces software rendering and is not suitable for production, obviously.

We (ChatGPT and I) made the strategic decision to retain nomodeset as a temporary safety measure during troubleshooting, modifying GRUB repeatedly as we tested configurations. This controlled approach prevented system lockout during kernel experiments.

Kernel Rollback to 6.8

After testing behavior across versions, it became clear that:

• Kernel 6.8 provided stable dual D700 initialization
• Newer kernels introduced instability in this specific hardware configuration

Rather than chase upstream regressions, we chose:

• To roll back to kernel 6.8
• To lock that branch for stability
• To prioritize workstation reliability over incremental kernel features

I confirmed:

• Both GPUs active
• OpenGL functional
• OpenCL recognized

 

[iMmARKAyLWARD]

Storage Architecture and Pegasus2 R4 Decisions

The Pegasus2 R4 introduced another challenge and required a key architectural decision.

Rather than configure RAID through hardware abstraction layers or complex mount strategies, we opted for clarity and control.

Key Decisions

1. Each of the 4 drives formatted individually to ext4
2. Mounted as embedded folders under /home
3. Persistent UUID-based mounts via /etc/fstab
4. noatime applied for performance optimization

Example structure:

/home/mark/Pegasus1
/home/mark/Pegasus2
/home/mark/Pegasus3
/home/mark/Pegasus4

I chose ext4 because it is a stable and mature filesystem with excellent Linux support. Meaning predictable behavior and straightforward recovery tools, without introducing cross-filesystem abstraction issues.

ChatGPT considered alternatives such as ZFS, which offers powerful features but adds complexity and memory overhead, Btrfs, which is advanced but less conservative in long-term stability perception, and hardware RAID, which can reduce transparency and control, ext4 was the best presented choice for this build.

I chose to mount the drives inside /home because it provides logical workflow integration, clean and intuitive pathing for media projects, simpler permission management, and reduced abstraction layer complexity.

While this approach is not as modular as mounting under /mnt and requires careful and disciplined /etc/fstab management, for a production content workstation the embedded /home mount structure ultimately improves workflow efficiency and reduces cognitive overhead during daily use.

 

[iMmARKAyLWARD]

Forum Assistance, ChatGPT and Where Adaptation Was Required

Throughout this process, community forums provided valuable insight. Being a COMPLETE NEWBIE however, I could not translate advice cleanly to keyboard strokes, because, well I have no idea about how to use linux OS ecosystem let alone configure my hardware. LOL

Helpful Forum Contributions

Forums assisted with:

• Understanding Mac Pro 6,1 GPU quirks
• Thunderbolt compatibility notes
• Kernel regression reports
• GRUB recovery strategies
• Wayland vs X11 behavior observations

The shared experience of other users confirmed that dual D700 instability on newer kernels was not unique.

So a big thanks to everyone here.

Where We Had to Adapt

However, several forum recommendations required modification:

MYTH 1. “Always Use the Latest Kernel”

Many users recommend updating to the newest available kernel; however, we chose a different path because stability mattered more than incremental feature updates. Kernel 6.8 proved empirically stable in our environment, whereas newer kernels introduced instability specific to the Tahiti-based D700 GPUs. In a production workstation context, practical reliability outweighs theoretical improvements.

---

MYTH 2. Permanent Wayland Enablement

Some threads pushed Wayland as default.

Why we diverged:

• D700 bring-up was more stable under X11.
• Wayland introduced display inconsistencies during troubleshooting.
• For Davinci Resolve workflows, X11 remains predictable.

We prioritized deterministic graphics behavior.

---

​

MYTH 3. RAID Over Individual ext4 Mounts

Forum suggestions included:

• RAID 0/5 configuration
• Btrfs/ZFS pooling

And in the Mac OS environment I used Raid 0 and created 1 16TB drive but backups and inevitable drive failures after so many years I decided to keep it simple and more manageable.

• Simplicity increases recoverability.
• Individual ext4 drives reduce catastrophic failure domains.
• Troubleshooting is cleaner.
• No additional memory overhead.

For a 64GB system, ZFS was viable — but not necessary.

---

​

MYTH 4. Removing nomodeset Immediately

Several suggestions indicated removing nomodeset immediately after boot.

We instead used it strategically:

• As a controlled diagnostic tool
• As a safety net during GPU iteration
• To prevent hard lockout

This disciplined approach prevented cascading failures.

---

​

Key Outcomes:

• Stable Ubuntu 24.04 LTS base
• Kernel 6.8 locked for GPU reliability
• Dual D700 fully accelerated
• ext4 Pegasus integration cleanly mounted
• Recovery pathways documented
• Snapshot rollback available

With the assistance of ChatGPT, I was able to:

• Weigh architectural pros and cons
• Interpret conflicting forum advice
• Prioritize production reliability
• Avoid unstable update paths
• Engineer toward workstation determinism

The result is not simply a Linux install.

It is a stable, high-performance content production workstation built deliberately around known hardware characteristics, long-term support strategy, and practical operational needs. This Mac Pro 6,1 now operates as intended, a reliable daily driver for professional media production.

 

[iMmARKAyLWARD]

The “Magical” Wi-Fi Resolution

Along the way in troubleshooting the D700 GPUs, I notice the WIFI was not working.

One of the more unexpected outcomes during this process was that Wi-Fi began functioning without a direct, isolated troubleshooting session focused on it.

Early in the build, wireless networking was either unavailable or unreliable. This was not initially prioritized because GPU stability and kernel bring-up were mission critical. However, after the kernel rollback to 6.8 and stabilization of the graphics stack, Wi-Fi began loading and operating normally. WOOHOO.

At first glance, this appeared coincidental. In reality, it was almost certainly the result of one or more of the following technical changes according to ChatGPT:

1. Kernel Compatibility Alignment

Rolling back to kernel 6.8 likely restored compatibility with the Mac Pro 6,1’s Broadcom wireless chipset. Apple hardware often depends on specific driver expectations, and newer kernels sometimes introduce regressions or altered driver behavior.

By returning to a known stable kernel branch:

• The correct Broadcom driver module loaded cleanly.
• Firmware dependencies aligned properly.
• No conflicting initialization occurred during early boot.

This is consistent with known Linux behavior on legacy Apple hardware.

2. Removal of Graphical Stack Instability

Prior GPU initialization failures may have been indirectly interfering with:

• Module loading order
• Systemd timing dependencies
• Driver bring-up sequence

Stabilizing amdgpu likely cleaned up the overall boot process, allowing Wi-Fi modules to load consistently.

Linux hardware bring-up is sequential. When early subsystems misbehave, seemingly unrelated components can fail as a downstream effect.

3. Package Alignment After OS Transition

Moving from elementary OS to Ubuntu 24.04 LTS ensured:

• Broader hardware driver support
• Better maintained kernel-module packaging
• Improved proprietary firmware handling

Ubuntu’s LTS branch tends to include more conservative and thoroughly tested firmware stacks, especially for widely deployed hardware such as Broadcom Wi-Fi chipsets in older Apple systems.

 

[iMmARKAyLWARD]

Reminder be gentle in your critique of this report and the declarations in it. I have a working machine, whereas had ChatGPT not been available, at this stage in my life that machine would still be collecting dust.

There may be points that seem overstated or irrelevant for a highly knowledgeable Linux user, and for that I encourage anyone willing to reply and continue my education in the world of Linux.

Thanks for your attention.