u/minaco5mko

AC Origins — which release actually installs? FitGirl and DODI both fail Been at this for about eight hours and I'm out of ideas.

Setup: CachyOS, kernel 7.1.3. Plenty of

space, installing to btrfs.

Game is AC Origins. I've tried basically every source:

- FitGirl v1.5.1 (the 31.6 GB one)

- FitGirl HV Gold Edition

- DODI #353 Gold Edition

- CODEX and CPY off Usenet

- cs.rin.ru threads

The weird part: both FitGirl repacks fail identically. The installer

opens fg-01.bin, reads exactly 31 bytes, writes ~29 MB of small files,

then just sits there burning CPU forever. Never reads another byte.

I checked with /proc/PID/fdinfo, the read offset is frozen at 31 and

RSS never moves. Not slow — actually hung.

DODI failed differently at first: unarc kept asking for ~1.9 GB

contiguous and getting refused because the biggest free block in the

32-bit address space was 1792 MiB. About 70 MiB short. Under GE-Proton

that error went away entirely and it landed on the same 31-byte stall

as FitGirl.

What I've already tried:

- proton-cachyos-slr, GE-Proton11, Proton Experimental, system Wine 11.12

- ntsync vs fsync (PROTON_NO_NTSYNC=1)

- ASLR off via setarch -R

- Limiting to 1 CPU (PROTON_CPU_TOPOLOGY=1:0)

- Clean install paths, no apostrophes or brackets, on both drives

- Fresh prefixes every time

- Verified every .bin against FitGirl's own MD5 file — all OK

Also worth mentioning: there is no 32-bit Wine on Arch anymore, it's

all new-WoW64 (wow64cpu.dll only), so I can't fall back to that.

Other DODI repacks install fine on this exact machine — AC Shadows at

155 GB, Stellar Blade at 61 GB — so it's not that repacks don't work

here in general.

Usenet is a dead end too, par2 came back with "not enough repair

blocks" so those articles are genuinely gone.

Has anyone seen a working version???

**1. Name of game:** Star Wars Outlaws

**2. CPU:** AMD Ryzen 7 9800X3D (Zen 5)

**3. GPU:** NVIDIA RTX 5070 Ti (driver 610.43.03, open modules)

**Distro:** CachyOS (Arch-based), kernel 7.1.3-2-cachyos

**4. Proton Version:** `cachyos-10.0-sunset-slr-LinUwUx` (LinUwUx-patched custom build,

in `compatibilitytools.d`). Confirmed it is *actually* the one running via

`compatdata/<appid>/config_info` → `CachyOS-10.1000-200` + LinUwUx paths.

Also have `Proton-GE11-1-LinUwUx` available.

**5. Game Launcher:** Steam (added as a non-Steam shortcut), Steam Linux Runtime 3.0 (sniper)

**6. Release Info:**

- Game build: January 2026, `Outlaws.exe`

- Crack: **DenuvOwO, hypervisor type — `DenuvOwO_SRC_V2` (V2-era), loader DLLs dated March 2026**

- Chain: `Outlaws.exe → version.dll (proxy) → DenuvOwO.dll`

- `AutoLoadHV=false` (Zen 5 shouldn't need the hypervisor)

- Game also has VMProtect on top of Denuvo

**Problem:** On launch I get **"Denuvo tried to delete the token. Is the hypervisor

running?"**, then a clean exit after ~5s with return code 0.

**7. Logs:** WINEDEBUG trace — key lines:

Loaded L"...\VERSION.dll" at ...: native

Loaded L"...\DenuvOwO.dll" at ...: native

Loaded L"...\upc_r2_loader64.dll" at ...: native

Loaded L"...\dbdata.dll" at ...: native

(no Denuvo/HV activity strings, no crash, rc=0 after 5s)

Full trace available on request.

---

**5. Steps already taken:**

- Confirmed `cpuid_fault` present; compiled and ran `arch_prctl(ARCH_SET_CPUID, 0)` →

returns 0, so **CPUID faulting works on kernel 7.1.3** (didn't need the 6.18 LTS kernel)

- UMIP disabled via `clearcpuid=514`, confirmed absent from `/proc/cpuinfo`

- Verified full crack file set present: `version.dll`, `DenuvOwO.dll`, `watchdog.exe`,

`token_amd.ini`, `token_intel.ini`, `upc_r2_loader64.dll`, `steamclient64.dll`

- Regenerated a clean prefix; found and fixed Steam silently falling back to Proton

Experimental despite the mapping (this had invalidated my earlier tests)

- Tried both LinUwUx builds

**What I think is wrong:** my loaders have no Wine awareness.

`strings DenuvOwO.dll | grep -c wine_get_version` → **0**, same for `version.dll`.

The 18 Jul 2026 `reflex.dll` that makes AC4 Black Flag work on this exact machine

returns **1**, plus it has `force_os` and literal "linux"/"windows" strings.

I tried dropping that July loader in as `DenuvOwO.dll` — it loads but is inert (never

reads `reflex.ini`, no activity strings), because the March `version.dll` proxy calls a

named export the July build doesn't have. Renaming it to `version.dll` also fails, since

it doesn't export `GetFileVersionInfoW`/`VerQueryValueW` and the game imports those.

**Questions:**

1. Is there an Outlaws release/loader built with **July 2026 or later** DenuvOwO

   (the Linux-aware generation)? I only see June v1.7 repacks.

2. Has anyone gotten **Outlaws specifically** running on Linux? Is the VMProtect layer

   the real blocker regardless of loader version?

3. Is the V2-era loader simply incompatible with LinUwUx, or am I missing a config step?

**I have searched this sub (wiki and previous threads) before posting.**

I’m trying to optimize an AI workflow for bleeding-edge Linux/ML debugging (Arch/CachyOS, CUDA, Python, unsloth, etc.).

Current stack:

- Claude = deep reasoning/mastermind

- Gemini 3.1 Pro = execution/logistics

- Perplexity = retrieval

Main problem: Gemini often gives high-friction or impractical fixes and degrades badly in long troubleshooting sessions. Example: suggested a long Podman workflow for an unsloth/Python issue where micromamba solved it much faster.

I also have access to hosted open models:

- Qwen 3 Coder 30B

- Qwen 3.5 122B

- Mistral Large 675B

- DeepSeek R1 Distill 70B

etc.

Question:

For people doing real-world Linux/ML/debugging workflows (not benchmarks), what currently works best as the “execution/logistics” model with strong web/recent-ecosystem awareness?

I care more about:

- practical fixes

- low friction

- stable long sessions

- debugging quality

than benchmark scores.

As the title says, every file I try to download in Zen Browser fails immediately. I tested other browsers and downloads work fine there, so the issue seems specific to Zen. Things I already checked: Flatseal permissions Different download locations Restarting the browser/system Nothing fixed it. Is anyone else having this issue on Arch Linux? Any ideas what could cause it?