Install Lutris, Heroic and GE-Proton on Fedora 45 / 44

GE-Proton is not a Wine build you unpack and point a launcher at anymore. Outside Steam, GloriousEggroll only supports it under umu-launcher, which runs Proton inside the same Steam Linux Runtime container Steam uses, and both Lutris and Heroic now set that up on their own. So getting GE-Proton on Fedora comes down to installing a launcher and knowing what it fetches the first time you press Play.

Original content from computingforgeeks.com - post 177747

This guide installs Lutris from the Fedora repo and Heroic from Flathub, makes GE-Proton the default in both, pins one GE-Proton build to a single game, and runs the Windows build of OpenTTD through each launcher. You’ll also see the four errors we hit and the fix for each. The lab VMs had no GPU, so this proves the setup and the failure modes rather than frame rates. Everything below was run on Fedora 45 in October 2026 with Lutris 0.5.22, Heroic 2.22.4 and GE-Proton11-11, and the Lutris install was repeated on Fedora 44.

GE-Proton runs through umu, not Wine

When you press Play on a Windows game in Lutris or Heroic with GE-Proton selected, the launcher does not call wine. It calls umu-run, and umu builds the same environment Steam would build for a Steam game. A launch passes through four layers, in this order:

1. The launcher, Lutris or Heroic, with your game settings.
2. umu-run, which fetches anything missing.
3. The steamrt4 runtime container, started by srt-bwrap.
4. The proton script inside GE-Proton, then the game.

The launcher picks the GE-Proton build, the prefix and the executable. umu downloads GE-Proton and the Steam Linux Runtime when they are missing, and the runtime gives Proton its own libraries. So what does that mean for you on Fedora? The first launch puts about 2.5 GB on disk on top of the launcher, prefix included, because GE-Proton and the runtime aren’t Fedora packages. The container still uses your host’s graphics driver, so the Mesa or NVIDIA packages on Fedora matter as much as they do for Steam. And the GE-Proton README is blunt about the old way. Running the tarball from a Wine runner directory without umu isn’t supported. Wine then falls back to whatever libraries your distro happens to ship.

You do not install umu-launcher yourself. The Fedora repos don’t carry it (dnf list "umu*" found no match on Fedora 45), and you don’t need them to, because Lutris downloads its own copy into ~/.local/share/lutris/runtime/umu on first start, and Heroic downloads its own the first time you launch a game. If you only use Steam, none of this applies; the Steam, Proton and NTSYNC setup for Fedora covers that path and the GPU driver side.

Lutris installs from the Fedora repo

Lutris is in the main Fedora repo, so there is no COPR or third-party repo to add, and updates arrive with the rest of the system through dnf upgrade. The package also recommends Wine, GameMode, gamescope and the 32-bit graphics libraries, which dnf installs by default:

sudo dnf install -y lutris

On a Fedora Cloud base with no desktop packages, the transaction was large. The summary below is from the first test VM, where the one replaced package came from updates-testing and does not matter for Lutris:

Transaction Summary:
 Installing:       413 packages
 Replacing:          1 package
 Downgrading:        1 package

Total size of inbound packages is 634 MiB. Need to download 634 MiB.
After this operation, 3 GiB extra will be used (install 3 GiB, remove 4 MiB).

It took 2 minutes 33 seconds. Do you run Workstation? It already has most of those libraries, so your transaction will be smaller. Confirm the version once dnf finishes:

lutris --version

Fedora ships the current upstream release:

lutris-0.5.22

If the version prints but the window never opens, the next error is the likely reason.

TypeError: expected str, bytes or os.PathLike object, not NoneType

Lutris crashed before drawing its window on the first start. The log line just above the traceback names the cause, Command 'xrandr' not found on your system. Lutris reads screen resolutions through the xrandr binary, the package doesn’t list it as a dependency, and the call passes None to subprocess when it is absent. Minimal and Cloud-based installs do not have it. Install it and start Lutris again:

sudo dnf install -y xrandr pciutils

pciutils is there because Lutris also logged Command 'lspci' not found, which it uses to identify your GPU. Neither package is needed by anything else in this guide.

Lutris needs the 32-bit Vulkan loader

Lutris decides whether DXVK is available by checking for both the 64-bit and the 32-bit libvulkan.so.1. If the i686 loader is missing, the DXVK toggle goes grey and the Runner options tab shows an error, even when vulkaninfo lists a working device. That’s what happened on our first VM:

The cause was the VM, not Lutris. Its 64-bit Mesa had come from updates-testing, so no i686 build in the stable repos matched the installed version, and dnf quietly dropped the 32-bit Recommends instead of failing. The second VM, whose Mesa came from the stable repos, installed 659 packages for the same dnf install lutris, 208 of them i686. Check which case you’re in before you change anything:

rpm -q vulkan-loader.i686 mesa-vulkan-drivers.i686 mesa-dri-drivers.i686 mesa-libGL.i686

Any line that says is not installed means Lutris will refuse DXVK. Install the four packages explicitly:

sudo dnf install -y vulkan-loader.i686 mesa-vulkan-drivers.i686 mesa-dri-drivers.i686 mesa-libGL.i686

On the updates-testing VM this pulled 37 packages and downgraded 18 64-bit Mesa packages to the stable versions so both architectures match. Restart Lutris afterwards, because it checks the libraries once at startup. Do you run an NVIDIA card? Then the 32-bit half of your driver is xorg-x11-drv-nvidia-libs.i686, which the RPM Fusion packages pull in by themselves on current Fedora once 32-bit Mesa or Wine is installed. The NVIDIA driver guide for Fedora covers the driver itself, and rpm -q xorg-x11-drv-nvidia-libs.i686 confirms the 32-bit part is there.

Lutris defaults to GE-Proton (Latest)

Current Lutris already uses GE-Proton for new Wine games, so there’s nothing to switch. Any Windows executable you own works for this section. If you want a free test game, OpenTTD publishes a Windows build and needs the OpenGFX graphics set next to it. These commands look up the current stable releases, then unpack both into ~/Games/openttd:

mkdir -p ~/Games/openttd ~/Downloads
cd ~/Downloads
V=$(curl -s https://cdn.openttd.org/openttd-releases/latest.yaml | grep -B1 "name: stable" | head -1 | awk '{print $3}')
G=$(curl -s https://cdn.openttd.org/opengfx-releases/latest.yaml | grep -B1 "name: stable" | head -1 | awk '{print $3}')
echo "OpenTTD $V, OpenGFX $G"
curl -LO https://cdn.openttd.org/openttd-releases/$V/openttd-$V-windows-win64.zip
curl -LO https://cdn.openttd.org/opengfx-releases/$G/opengfx-$G-all.zip

The echo printed OpenTTD 15.3, OpenGFX 8.0 in our run. Extract the game, flatten its folder, and drop OpenGFX into the baseset directory where the game looks for graphics. Install the 7zip package first if 7z isn’t on your system yet, and run this in the same terminal so $V and $G are still set:

sudo dnf install -y 7zip
cd ~/Games/openttd
7z x -y ~/Downloads/openttd-$V-windows-win64.zip
mv openttd-$V-windows-win64/* . && rmdir openttd-$V-windows-win64
cd baseset && 7z x -y ~/Downloads/opengfx-$G-all.zip

Now add the game to your library. Click the + button at the top left of the Lutris window to open the add dialog:

Pick Add locally installed game. You fill in four fields across the tabs of the form that opens:

1. Game info: name OpenTTD, runner Wine.
2. Game options: the full path to openttd.exe.
3. Game options: a new Wine prefix directory.
4. Runner options: keep GE-Proton (Latest), then Save.

On our VM the executable was /home/kenneth/Games/openttd/openttd.exe and the prefix /home/kenneth/Games/prefixes/openttd, which does not need to exist yet because Proton creates it on the first launch. With the 32-bit loader in place, the Runner options tab shows DXVK enabled and GE-Proton selected by default:

The Wine version list held three entries on a fresh install: Custom, System (11.0 (Staging)) from the Fedora wine-core package, and GE-Proton (Latest). Only the last one goes through umu. The System entry runs the Fedora build of Wine directly, which is the setup our Wine on Fedora guide covers.

The first launch fills 2.5 GB of disk

Double-click the game. You’ll see nothing happen for a while, because umu is downloading GE-Proton and the runtime before Proton creates the prefix. On our VM, 2 minutes 30 seconds passed between the click and the game process starting. Three directories filled up during that wait, and du -sh on each gives the sizes below:

• GE-Proton in ~/.local/share/Steam/compatibilitytools.d, 1.6 GB
• The runtime in ~/.local/share/umu/steamrt4, 703 MB
• The Wine prefix you chose, 234 MB

GE-Proton arrived as a 565 MB tarball and unpacked to 1.6 GB, and the prefix held 234 MB before the game had written anything. umu stores GE-Proton under a Steam path even when Steam is not installed. That’s the same compatibilitytools.d directory a native Steam install reads custom Proton builds from. The process tree while the game ran shows the container in the middle of the chain:

ps -eo pid,args --forest | grep -E "lutris-wrapper|umu-run|srt-bwrap|proton runinprefix|openttd.exe" | grep -v grep

Read it top to bottom. gamemoderun wraps umu because Lutris turned GameMode on by default once the package was present, srt-bwrap is the runtime container, and the Windows executable runs under GE-Proton inside it (lines trimmed to 160 characters):

  14895  |   \_ /usr/bin/python3 /usr/share/lutris/bin/lutris-wrapper OpenTTD 0 0 gamemoderun /home/kenneth/.local/share/lutris/runtime/umu/umu-run /home/kennet
  14897  |       \_ python3 /home/kenneth/.local/share/lutris/runtime/umu/umu-run /home/kenneth/Games/openttd/openttd.exe
  14929  |           \_ /home/kenneth/.local/share/umu/steamrt4/pressure-vessel/libexec/steam-runtime-tools-0/srt-bwrap --args 25 /usr/lib/pressure-vessel/from-
  15054  |               \_ /usr/lib/pressure-vessel/from-host/libexec/steam-runtime-tools-0/pv-adverb --prefix=/usr/lib/pressure-vessel/from-host --generate-lo
  15078  |                   \_ python3 /home/kenneth/.local/share/Steam/compatibilitytools.d/GE-Proton11-11-x86_64/proton runinprefix /home/kenneth/Games/opent
  15138  |                   \_ X:\Games\openttd\openttd.exe

OpenTTD then opened its title screen. It also warned no compatible GPU found. Hardware acceleration disabled, which is the lab VM talking: it has no GPU, only Mesa’s llvmpipe. On real hardware that message does not appear.

Later launches skip the download and start in seconds. The runtime and the GE-Proton build stay in place until a newer GE-Proton release appears, and then “Latest” downloads it on the next launch.

Pin a GE-Proton build per game

“Latest” moves often. Heroic’s GE-Proton list showed GE-Proton11-10 and GE-Proton11-11 released on the same day, and a game that runs today can break after the next build. Lutris lists any Proton directory in ~/.local/share/lutris/runners/wine as its own Wine version, so you can freeze one game while the rest follow Latest. Fetch the current tag from the GitHub API first:

GE_VER=$(curl -s https://api.github.com/repos/GloriousEggroll/proton-ge-custom/releases/latest | grep -oP '"tag_name": "\K[^"]+')
echo "$GE_VER"

It printed GE-Proton11-11. Download the tarball and its checksum, verify, and unpack it into the Lutris Wine directory:

cd ~/Downloads
curl -LO https://github.com/GloriousEggroll/proton-ge-custom/releases/download/${GE_VER}/${GE_VER}-x86_64.tar.gz
curl -LO https://github.com/GloriousEggroll/proton-ge-custom/releases/download/${GE_VER}/${GE_VER}-x86_64.sha512sum
sha512sum -c ${GE_VER}-x86_64.sha512sum
mkdir -p ~/.local/share/lutris/runners/wine
tar -xf ${GE_VER}-x86_64.tar.gz -C ~/.local/share/lutris/runners/wine/

We downloaded to ~/Downloads rather than /tmp, which is RAM-backed on Fedora; delete the tarball afterwards. The checksum has to say OK before you extract anything. Ours printed GE-Proton11-11-x86_64.tar.gz: OK. List the Wine directory, because the name in it is exactly what Lutris will show you:

ls ~/.local/share/lutris/runners/wine/

One directory per build you’ve unpacked:

GE-Proton11-11-x86_64

Restart Lutris so it rescans the directory, then right-click your game, choose Configure, and open Runner options. The Wine version list now carries the pinned build above System and Latest:

Select it, save, and launch the game. To prove which build umu received from your launcher, read the environment of the running umu-run process while the game is open:

tr "\0" "\n" < /proc/$(pgrep -f umu-run | head -1)/environ | grep -E "^(PROTONPATH|GAMEID|WINEPREFIX)="

PROTONPATH should point at the pinned directory, not at the Steam path from the Latest run:

WINEPREFIX=/home/kenneth/Games/prefixes/openttd
PROTONPATH=/home/kenneth/.local/share/lutris/runners/wine/GE-Proton11-11-x86_64
GAMEID=umu-default

The same terminal session, with lutris --version and the disk use of the runtime, GE-Proton and the prefix, looked like this:

GAMEID=umu-default means no per-game protonfix applied, because OpenTTD added by hand has no store ID. For games from GOG, Epic and the other stores Lutris connects to, it looks the title up in umu’s game database, and GE-Proton’s protonfixes can then apply per-game tweaks. A pinned build also stops getting those fixes, so move it forward when a newer release fixes your game.

Heroic installs from Flathub

Heroic is not in the Fedora repos. The project publishes a Flathub app and an RPM on its GitHub releases page, and you give up something either way:

• Flatpak: automatic updates, about 3.1 GB with runtimes
• RPM: 370 MB, unsigned, no repo, manual updates

We’d take the Flatpak. It updates with flatpak update or GNOME Software like the rest of your Flatpak apps, while the RPM has no repo behind it and every new release is a manual download. The 3.1 GB is the 623 MB app plus about 2.5 GB of Freedesktop runtimes, which other Flatpak apps share once they’re on disk. Add the Flathub remote if flatpak remotes does not list it, then install Heroic system-wide. The Flatpak and Flathub guide for Fedora explains how Fedora’s own Flathub setup differs, if your remote list looks unfamiliar:

sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
sudo flatpak install -y flathub com.heroicgameslauncher.hgl

The install took 4 minutes 32 seconds and pulled the app plus the Freedesktop runtime with its 32-bit Compat.i386 and GL32 extensions, which Proton needs inside the sandbox. Check the installed version:

flatpak info com.heroicgameslauncher.hgl | grep -E "Version|Installed"

Flathub carries the same release as GitHub:

       Version: v2.22.4
Installed Size: 623.3 MB

Heroic now shows up in your application menu. The first start is where it makes its own decision about Proton, which the next section after the RPM notes covers.

Flatpak system operation GetRevokefsFd not allowed for user

Our first attempt ran flatpak install without sudo over SSH, and it failed after resolving the runtimes with F: Failed to get revokefs-fuse socket from system-helper: Flatpak system operation GetRevokefsFd not allowed for user. A system-wide install needs permission from polkit, and an SSH session has no polkit agent to ask you for a password. Running the same command with sudo, as shown above, installed cleanly.

Installing the Heroic RPM instead

The RPM route works, with one surprise. On Fedora 45, rpm --eval '%{_pkgverify_level}' prints all, so rpm refuses unsigned packages. The Heroic RPM carries no signature. rpm -K reports digests SIGNATURES NOT OK for it. If you try a direct rpm -U, it stops with package heroic-2.22.4-1.x86_64 does not verify: no signature. dnf still installs it for you, because local files skip the OpenPGP check by default:

cd ~/Downloads
HEROIC_URL=$(curl -s https://api.github.com/repos/Heroic-Games-Launcher/HeroicGamesLauncher/releases/latest | grep browser_download_url | cut -d\" -f4 | grep -E "linux-x86_64\.rpm$")
curl -LO "$HEROIC_URL"
sudo dnf install -y ./Heroic-*-linux-x86_64.rpm

dnf says so in its output, which is the line to look for when you wonder why an unsigned package went in:

Warning: skipped OpenPGP checks for 1 package from repository: @commandline
Complete!

The RPM installs Heroic to /opt/Heroic with a heroic command in /usr/bin. The rest of this guide uses the Flatpak, which keeps its settings, Proton builds and library under ~/.var/app/com.heroicgameslauncher.hgl, so it shares nothing with an RPM install. Pick one.

Heroic downloads Proton-CachyOS first

Heroic does not start with GE-Proton. Within seconds of the first launch, with no Wine version installed, its log showed Start installation of wine version Proton-CachyOS-latest, a 331 MB download we never asked for. Wine Manager confirms it, with the Proton-CachyOS tab open and the download in progress:

Proton-CachyOS is a separate Proton build maintained by the CachyOS team, and letting it finish does no harm. To follow this guide and use GE-Proton, switch to it in three steps:

1. Open Wine Manager and cancel the Proton-CachyOS download if unwanted.
2. Download GE-Proton-latest from the GE-Proton tab.
3. Check Settings, Game Defaults, WINE for the new default.

The GE-Proton tab lists every recent build with its date and size, so you can also pin a specific one here, as with Lutris:

Downloads from GitHub were slow in that window. GE-Proton-latest took 19 minutes 48 seconds at 200 to 500 KB/s. A manual curl of the same file running alongside it was just as slow, while umu had fetched it for Lutris in under two minutes earlier that morning. Leave Heroic open until it finishes. Once it was the only installed version, Game Defaults picked it up on its own:

Game Defaults only apply to games you add or install afterwards. A game that’s already in the library keeps its own Wine version, which you change from that game’s settings page.

Heroic’s sandbox can’t read ~/Games

Heroic exists for Epic, GOG and Amazon libraries, and signing in to any of them fills the library. For a game you already have on disk, ADD GAME on the Library page does the same job as the local install in Lutris. The Flatpak can read only a few places in your home directory, though: ~/Games/Heroic, Documents, Desktop, ~/.steam, ~/.local/share/lutris, plus /mnt, /media and /run/media for second drives. Plain ~/Games isn’t one of them, so copy the game under ~/Games/Heroic first. This uses the OpenTTD folder from the download block in the Lutris section; if you skipped Lutris, run that block first. ~/Games/Heroic exists once Heroic has started once.

cp -a ~/Games/openttd ~/Games/Heroic/OpenTTD

Then click ADD GAME and fill in the form from top to bottom. Heroic fetched cover art for OpenTTD by itself:

1. Game/App Title: OpenTTD.
2. Platform: Windows.
3. Wine settings: suggested prefix, GE-Proton-latest.
4. Executable: ~/Games/Heroic/OpenTTD/openttd.exe, then FINISH.

The filled form looked like this before we clicked FINISH:

Press the green play button on your game card. Heroic downloaded umu into its own tools/runtimes/umu directory on this first game launch, and umu then logged Running 'GE-Proton11-11-x86_64' using runtime 'steamrt4', and it reused the runtime Lutris had already downloaded, because the Flatpak is allowed to write ~/.local/share/umu. GE-Proton itself is not shared. Heroic keeps its own 1.6 GB copy in ~/.var/app/com.heroicgameslauncher.hgl/config/heroic/tools/proton, because Heroic installs its Proton builds under its own tools directory by design, and the sandbox can’t see ~/.local/share/Steam unless a native Steam install links it through ~/.steam.

Same game, same GE-Proton build, a second launcher. The difference shows up as soon as the game lives anywhere else.

No available language packs (invalid versions?)

We added the untouched copy from ~/Games/openttd as a second entry. The file picker accepted it, but the path it handed Heroic was /run/user/1001/doc/kDauo_6Jb871BxQdy79v2Q/openttd.exe. That’s the Flatpak document portal, which exports the single file you picked and nothing next to it. OpenTTD started, found no lang folder beside its executable, and stopped:

Any game you add this way that loads data files from its own folder fails the same way, each with its own error. You can either keep games under ~/Games/Heroic, or give the Flatpak read access to the folder that holds them:

flatpak override --user --filesystem=~/Games com.heroicgameslauncher.hgl

The override only applies to a new sandbox, so stop every Heroic process before you start it again and add the game once more:

flatpak kill com.heroicgameslauncher.hgl
flatpak override --user --show com.heroicgameslauncher.hgl

The second command should print filesystems=~/Games;. After the restart the picker returned the real path, /home/kenneth/Games/openttd/openttd.exe, and OpenTTD started normally. Use the narrowest folder that holds your games rather than --filesystem=home.

Where Lutris and Heroic keep GE-Proton on Fedora

When a game misbehaves, you need to know which copy of GE-Proton ran it and which prefix it wrote to, before you change anything. These are the paths from our two test machines, with the Lutris RPM and the Heroic Flatpak:

Item	Lutris (Fedora RPM)	Heroic (Flatpak)
Default Wine version	GE-Proton (Latest)	Proton-CachyOS-latest on first launch
GE-Proton downloaded by the launcher	~/.local/share/Steam/compatibilitytools.d/	~/.var/app/com.heroicgameslauncher.hgl/config/heroic/tools/proton/
Pinned GE-Proton you add by hand	~/.local/share/lutris/runners/wine/	Wine Manager, GE-Proton tab
umu-launcher	~/.local/share/lutris/runtime/umu/	~/.var/app/com.heroicgameslauncher.hgl/config/heroic/tools/runtimes/umu/, fetched on first game launch
Steam Linux Runtime	~/.local/share/umu/steamrt4	Same directory, shared
Default prefixes	Whatever you set per game	~/Games/Heroic/Prefixes/
Folders it can read	Anything your user can	~/Games/Heroic, Documents, Desktop, ~/.steam, ~/.local/share/lutris, ~/.local/share/umu, /mnt, /media, /run/media, plus overrides

Two rows explain most of the disk use. Each launcher keeps its own GE-Proton at 1.6 GB per build, and builds pile up as Latest moves, so delete old directories from those two paths once no game is pinned to them. The runtime row is the cheap one, because one 703 MB copy serves both. If you also play through Steam, the Fedora 45 post-install checklist covers RPM Fusion and the rest of the desktop setup that games lean on.