Framework
Desktop with Ryzen AI Max+ 395
Thirteen exact-model owner accounts include eight people running Omarchy, two on Arch Linux and three on other Linux distributions, with direct evidence on GPU stability, local AI, displays, firmware and sustained performance.
Bottom line
The Framework Desktop is a credible, unusually powerful Omarchy machine, but the retained reports do not support an unqualified stability claim. Exact owners have run Omarchy from 3.0.1 through 4.0.0 and used the Radeon 8060S for the desktop and local inference. The local-AI setup was not consistent: one 128GB owner found that LM Studio detected the GPU on Fedora but not Omarchy, while another reached GPU inference through a manual ROCm path. The first owner later returned a likely faulty unit after loud power-supply noise, rear-port failures and sleep-related peripheral loss across three distributions. A separate cluster of 3.5-to-3.7 reports documents Chromium and video-triggered GPU lockups. No retained exact owner has retested that failure on 4.0.2.
For a general workstation, the 64GB and 128GB versions have the same CPU, GPU and memory bandwidth; buy 128GB for model capacity, large virtual-machine sets or unusually memory-heavy work, not for higher frame rates. Existing owners should update to the current BIOS and kernel before debugging peripherals or ROCm. New buyers should use the return window to test power-supply noise, every rear port and repeated suspend with the intended peripherals; the one owner who failed those checks was offered a board swap, so that result is serious but not a family-wide verdict. If the Chromium hard lock recurs, increased BIOS graphics memory and software video decoding are owner-tested mitigations, not universal fixes. Buyers focused on CUDA, OptiX, maximum gaming value or a conventional GPU upgrade path should choose a different system.
What is reported
6 findings with cited evidenceInstall and boot
Eight exact owners report installed Omarchy systems across releases from 3.0.1 through 4.0.0. An exact Arch owner initially lost video during the live installer with an Apple Studio Display, then booted the same ISO and display after intervening firmware updates.
A normal installation has a positive owner baseline. With an unusual USB-C display, keep HDMI or a simpler monitor available for setup and update the BIOS before treating a black screen as an installer failure.
Desktop and graphics
The Radeon 8060S drives ordinary desktop use, Arch gaming and local inference, but exact Omarchy owners reported hard GPU lockups around Chromium and video on 3.5 through 3.7. Removing Omarchy's default VA-API enables helped some owners; another exact owner still needed a 32GB BIOS graphics-memory setting. There is no exact 4.0.2 retest of the original failure.
Do not read the closed issue as proof that the lower-level AMD failure is gone. Test hardware-accelerated video under the intended BIOS memory setting before relying on the machine, especially with several high-resolution displays.
Wi-Fi and Bluetooth
Framework's current matrix lists Wi-Fi and Bluetooth as requiring setup on Arch and rates the distribution as carrying some stability risk. The retained exact Omarchy accounts do not isolate either radio well enough for a working verdict.
Plan to follow the Framework Arch package guidance and verify both radios separately. This is official transfer guidance, not an exact Omarchy owner result.
Suspend and resume
One exact Omarchy owner reported that waking with the power button also delivered the power-key action after unlock, while keyboard wake was normal. A second 128GB owner reported that every sleep crashed or disabled peripherals across Omarchy, Fedora and Ubuntu and returned the unit after Framework offered a board swap. The broader Linux record ties some rear-USB resume failures to an upstream xHCI and GPU ordering race whose fix reached current Arch kernels.
Use a current kernel, then test wake by keyboard and power button plus every occupied rear USB port. A successful short suspend does not establish a heavily configured display and peripheral setup; repeated cross-distribution failure on one unit may justify hardware support rather than more operating-system changes.
External displays and docks
An exact Arch owner recovered an Apple Studio Display installation path after firmware updates. On Omarchy 4.0.0, an exact three-monitor owner documented a screensaver focus race that prevents the normal idle and display-power sequence. Framework also continues to track intermittent USB-C Power Delivery and DisplayPort Alt Mode handshakes.
One or two conventional displays have the stronger baseline. Treat three-monitor idle behavior and USB-C display chains as separate acceptance tests, including sleep, wake and DPMS rather than initial picture alone.
Battery, power and thermals
Independent Windows and Ubuntu measurements describe a quiet, thermally controlled 120-watt system with roughly 10-to-12-watt idle draw and strong sustained CPU performance. One exact 128GB owner instead returned a unit after finding the power supply unacceptably loud alongside rear-port and resume failures; Framework offered a board swap.
The controlled reviews provide the stronger family baseline, while the return report defines a practical defect check. Listen to the power supply at idle and load during the return window instead of assuming every loud unit is normal for the chassis.
Changes over time
12 dated events- Power-button wake also opens the system menu
An exact Omarchy 3.0.1 owner separates the bad power-button path from normal keyboard wake.
- Owners split on LM Studio GPU detection
One 128GB owner reports that Fedora detects the GPU while Omarchy does not; another exact owner reaches working Omarchy inference through Mesa, Vulkan, ROCm and a gfx1151 override.
- One owner returns a likely faulty unit
After failures across Omarchy, Fedora and Ubuntu, the 128GB owner reports loud power-supply noise, nonworking rear ports and peripherals lost on wake. Framework offers a board swap; the owner returns the machine instead.
- BIOS 3.04 adds a long boot handoff
An exact Fedora owner measures a greater-than-two-minute GRUB-to-kernel delay after the firmware update.
- Framework Desktop owners confirm the 3.05 boot recovery
Exact and corroborating Desktop reports say the slow handoff is gone after moving to BIOS 3.05.
- Exact owners reproduce hard GPU lockups
Framework 395 owners place the failure on Omarchy 3.5 and 3.6, often during Chromium video, after several kernel, firmware, Mesa and browser experiments fail to isolate a universal fix.
- Omarchy removes its default VA-API feature enables
The shipped migration removes two browser feature flags after seven-hour clean owner testing and closes the original issue.
- Later crash outcomes remain configuration-dependent
One exact owner still reports two crashes a day at the default graphics-memory setting with stronger software-decoding flags, while a 32GB BIOS setting remains stable for that machine.
- The processor-specific browser workaround closes unmerged
The proposed migration does not ship; the maintainer favors a BIOS memory change while waiting for an AMD fix.
- An exact Debian report finds ROCm output corruption under memory pressure
The open report binds repeating invalid tokens to the 8060S, ROCm 7.2 and a reproducible multi-model memory-pressure condition.
- Three monitors expose an Omarchy screensaver race
On 4.0.0, the screensaver terminates during sequential launch and prevents the normal idle lock and display-power sequence; the same configuration works with two monitors.
- Omarchy 4.0.2 becomes the current release boundary
The audit checks the tagged release and current browser defaults, but finds no exact Framework owner retest of the original Chromium lockup on 4.0.2.