Install Wine on Fedora 45 / 44: Fedora Repo, WineHQ and NTSYNC

Wine on Fedora is one dnf command, because Fedora packages the current stable release itself. What breaks is everything older guides add on top. WineHQ has no Fedora 45 repository yet, its Fedora 44 builds will not install on Fedora 45, and the NTSYNC driver that Wine 11 wants is shipped in the kernel but never loaded. The commands below were run on Fedora 45 (beta, kernel 7.2) and Fedora 44 in October 2026, on fresh machines and with real Windows programs.

Original content from computingforgeeks.com - post 18256

The guide covers the Fedora package, one prefix running 32-bit and 64-bit programs through WoW64, turning on NTSYNC, the WineHQ repository for devel and staging builds on Fedora 44, Winetricks, and a clean removal. If you are still on an older release, upgrading Fedora 44 to 45 first changes nothing here except the WineHQ section.

Which Wine install to pick on Fedora 45 and 44

Use the Fedora package unless you need a development snapshot. Both releases get the same build, and it already carries the staging patch set. The table is what our two lab machines showed.

Item	Fedora 45	Fedora 44
Fedora wine package	11.0-3.fc44 (staging patches)	11.0-3.fc44 (staging patches)
Packages pulled by dnf install wine	367	388
WineHQ repository	No fedora/45 tree (404)	stable 11.0.0, devel 11.19, staging 11.19
WineHQ Fedora 44 build on this release	Fails: needs libavcodec.so.62	Installs
/dev/ntsync after boot	Missing until modprobe ntsync	Missing until modprobe ntsync
i686 packages needed for 32-bit programs	None	None

Install Wine from the Fedora repository

Check what the repository offers before installing. Name the architecture, because the repository also carries an i686 build of the same package:

dnf info wine.x86_64

On Fedora 45 the release tag still reads fc44. Fedora 45 inherited the Fedora 44 build instead of rebuilding it, so both releases run identical Wine binaries:

Available packages
Name           : wine
Epoch          : 0
Version        : 11.0
Release        : 3.fc44
Architecture   : x86_64
Download size  : 11.6 KiB
Installed size : 0.0   B
Source         : wine-11.0-3.fc44.src.rpm
Repository     : fedora
Summary        : A compatibility layer for windows applications
URL            : https://www.winehq.org/
License        : LGPL-2.1-or-later

Install it:

sudo dnf install -y wine

Budget for the size. On a minimal Fedora 45 system this was 367 packages, a 773 MiB download and about 3 GiB on disk, most of it fonts, GStreamer, Mesa, DXVK and Wine Mono. Fedora 44 pulled 388 packages. None of them are i686 builds, which matters later. Confirm the version:

wine --version

The “(Staging)” suffix is expected. Fedora builds its wine package with the wine-staging patches applied:

wine-11.0 (Staging)

Older guides say the wine64 command is gone in Wine 11. That is true for upstream and WineHQ builds, not for Fedora. Fedora ships /usr/bin/wine64 as the real loader and points /usr/bin/wine at it through alternatives, so both names work. Use wine in scripts and it behaves the same on every build.

Create a prefix and run 32-bit and 64-bit programs

The first Wine command creates the default prefix in ~/.wine. Running wineboot does it explicitly and returns when it is done:

wineboot -i

It took 15 seconds on our 4 vCPU machines and left a 1.5 GiB prefix, because the packaged Wine Mono and DXVK get copied in. The console fills with fixme and err lines about RpcSs and auto-start services. Those are normal on first boot of a prefix and do not mean it failed. Check the Windows version the prefix reports:

wine cmd /c ver

A new prefix identifies itself as Windows 10:

Microsoft Windows 10.0.19045

Fedora builds Wine in the new WoW64 mode. One 64-bit prefix runs 32-bit Windows programs, and no 32-bit Linux libraries are needed. We tested this with the 64-bit and 32-bit installers of 7-Zip, taken from the official GitHub release:

mkdir -p ~/Downloads && cd ~/Downloads
curl -LO https://github.com/ip7z/7zip/releases/download/26.03/7z2603-x64.exe
curl -LO https://github.com/ip7z/7zip/releases/download/26.03/7z2603.exe

Install the 64-bit build silently, then the 32-bit build into its own folder:

wine 7z2603-x64.exe /S
wine 7z2603.exe /S /D='C:\7zip32'

Run the 32-bit console binary to prove the i386 side works:

wine 'C:\7zip32\7z.exe' i | head -3

It prints its x86 banner while rpm -qa lists zero i686 packages on the machine:

7-Zip 26.03 (x86) : Copyright (c) 1999-2026 Igor Pavlov : 2026-09-03

Wine maps the whole Linux filesystem to the Z: drive, and it accepts plain Linux paths as arguments. This compresses a Linux file with the 64-bit 7-Zip, writing the archive to the home directory:

cd ~
wine 'C:\Program Files\7-Zip\7z.exe' a etc-test.7z /etc/os-release

7-Zip reads the file through Wine and reports a clean run:

7-Zip 26.03 (x64) : Copyright (c) 1999-2026 Igor Pavlov : 2026-09-03

Scanning the drive:
1 file, 650 bytes (1 KiB)

Creating archive: etc-test.7z

Add new data to archive: 1 file, 650 bytes (1 KiB)


Files read from disk: 1
Archive size: 477 bytes (1 KiB)
Everything is Ok

GUI programs open as normal windows on your desktop. Installers also drop menu entries under ~/.local/share/applications/wine, and desktop environments list them in the application menu. This is the file manager browsing the Linux home directory through Z::

For per-application Windows versions, DLL overrides and drive mappings, open the configuration tool:

winecfg

The Fedora build shows a Staging tab next to the usual ones, another sign of the staging patch set:

Check the Wine Application Database before buying or depending on a specific program. Ratings there are per Wine version, so read the newest reports first.

Turn on NTSYNC

NTSYNC is a kernel driver that implements Windows synchronization objects natively. Wine 11 uses it automatically when /dev/ntsync exists, which helps games and heavily threaded programs. Fedora builds it as a module, CONFIG_NTSYNC=m, and nothing loads it. On both releases the device was missing after boot, and installing Wine did not change that:

ls -l /dev/ntsync

The module has no device alias, so opening the path does not autoload it either:

ls: cannot access '/dev/ntsync': No such file or directory

Load it now and on every boot:

sudo modprobe ntsync
echo ntsync | sudo tee /etc/modules-load.d/ntsync.conf

The kernel creates the device world-readable and writable (crw-rw-rw-), so no udev rule or group membership is needed. At the default debug level Wine prints nothing when it picks NTSYNC up. The reliable check is to count the ntsync handles held by wineserver. With a Wine program running, run:

ls -l /proc/$(pidof -s wineserver)/fd | grep -c ntsync

With Notepad open, wineserver held 576 ntsync handles. With the module unloaded, the same test returned 0 and Wine fell back to its server-based synchronization:

The result held after a reboot, with the module loaded from modules-load.d. The kernel NTSYNC documentation describes the objects it provides.

Use the WineHQ repository for devel and staging builds

The WineHQ repository is only worth adding for the development or staging branches, which Fedora does not package. It currently works on Fedora 44 only. The Fedora 45 situation is covered after the steps.

Add the repository with the dnf5 syntax:

sudo dnf config-manager addrepo --from-repofile=https://dl.winehq.org/wine-builds/fedora/44/winehq.repo

List the newest build of each branch:

dnf repoquery --repo=WineHQ --latest-limit=1 --qf "%{name} %{evr} %{arch}\n" winehq-stable winehq-devel winehq-staging

The stable branch matches what Fedora already ships. Devel and staging track the two-weekly development snapshots:

winehq-devel 1:11.19-1.1 x86_64
winehq-stable 1:11.0.0-2.1 x86_64
winehq-staging 1:11.19-1.1 x86_64

A higher number is not a newer stable release. The devel and staging snapshots are development builds on the way to the next stable release, and the stable branch is what Fedora ships.

Error: “installed package wine-desktop conflicts with wine-desktop provided by winehq-devel”

The WineHQ and Fedora packages cannot be installed side by side. With the Fedora build present, sudo dnf install winehq-devel stops at the transaction check. Dnf repeats the two conflict lines for every older devel build in the repository; those repeats are cut here:

Failed to resolve the transaction:
Problem: problem with installed package
  - installed package wine-desktop-11.0-3.fc44.noarch conflicts with wine-desktop provided by winehq-devel-1:11.19-1.1.x86_64 from WineHQ
  - package winehq-devel-1:11.19-1.1.x86_64 from WineHQ conflicts with wine-desktop provided by wine-desktop-11.0-3.fc44.noarch from fedora
  - conflicting requests
You can try to add to command line:
  --allowerasing to allow removing of installed packages to resolve problems
  --skip-broken to skip uninstallable packages

Don’t take the --allowerasing hint. We did, and the transaction succeeded, but wine was then “command not found”. The scriptlet of the removed Fedora package ran alternatives --remove after WineHQ had placed its symlink, and deleted /usr/bin/wine and /usr/bin/wineserver. rpm -V winehq-devel reports both as missing, and sudo dnf reinstall winehq-devel puts them back. Remove the Fedora package first instead, together with the Fedora Winetricks package, which pins wine-common and would hold half of the Fedora build in place:

sudo dnf remove -y wine winetricks
sudo dnf install -y winehq-devel

Swap winehq-devel for winehq-staging if you want the staging patches on top of the snapshot. On our Fedora 44 machine the removal took out 203 packages, and the WineHQ install added 26. Dnf asks to import the WineHQ signing key on first use, fingerprint D43F 6401 4536 9C51 D786 DDEA 76F1 A20F F987 672F. The build installs to /opt/wine-devel (1.8 GiB) and links its commands into /usr/bin:

wine --version

The upstream build reports a plain version string, with no staging tag, and rpm -V winehq-devel comes back clean:

wine-11.19

“Wine could not find a wine-mono package” with the WineHQ build

The first run of the WineHQ build in an existing prefix stopped on this dialog. Scripted runs hang until someone clicks it:

The Fedora wine-mono package matches stable Wine. The current devel snapshot looks for Mono 11.3.0, so it ignores the installed copy. Clicking Install downloads it. On a headless or scripted setup, put the MSI in the Wine download cache before the prefix is created or updated. Wine installs it from there without asking:

mkdir -p ~/.cache/wine
curl -L -o ~/.cache/wine/wine-mono-11.3.0-x86.msi https://dl.winehq.org/wine/wine-mono/11.3.0/wine-mono-11.3.0-x86.msi
wineboot -u

Later devel snapshots may want a newer Mono. The version each Wine release expects is listed on the Wine Mono wiki page. On a fresh prefix the update took 15 seconds, showed no dialog and left C:\windows\mono in place. NTSYNC works the same with the WineHQ build: wineserver held 564 ntsync handles with Notepad open.

WineHQ on Fedora 45: 404, then “nothing provides libavcodec.so.62”

WineHQ has not published a fedora/45 tree, so the Fedora 45 repo file returns 404:

>>> Status code: 404 for https://dl.winehq.org/wine-builds/fedora/45/winehq.repo (IP: 151.101.194.217)
Failed to download repository configuration file "https://dl.winehq.org/wine-builds/fedora/45/winehq.repo": Failed to download files

Pointing Fedora 45 at the Fedora 44 repository is the usual workaround for a missing third-party tree, as in our guide to third-party repo 404s on Fedora. It doesn’t work for Wine. The WineHQ stable and devel builds we tried both link against FFmpeg 8 libraries, and Fedora 45 moved to FFmpeg 9:

Fedora 45 only provides libavcodec.so.63, and no package in the Fedora repositories ships the old soname. Remove the repository again so it does not break dnf upgrade:

sudo rm /etc/yum.repos.d/winehq.repo

On Fedora 45, stay on the Fedora package until WineHQ publishes Fedora 45 builds. If you need a newer runner for one game, Bottles from Flathub ships its own Wine builds inside the Flatpak runtime and does not touch system libraries. Our Flatpak and Flathub guide for Fedora covers the setup.

Install Winetricks

Winetricks installs the Microsoft runtimes and fonts that many programs expect. With the Fedora Wine package, install the Fedora build of Winetricks:

sudo dnf install -y winetricks

The Visual C++ 2015-2022 runtime is the one most modern Windows software needs. Install it unattended:

winetricks -q vcrun2022

It downloads the installer from Microsoft, unpacks it with cabextract and runs it, in 13 seconds here. The cabextract warning about extra bytes at the end of the file is harmless:

Executing cabextract -q --directory=/home/josphat/.wine/dosdevices/c:/windows/system32 /home/josphat/.wine/dosdevices/c:/windows/temp/_vcrun2022/win64/a12 -F msvcp140.dll
/home/josphat/.wine/dosdevices/c:/windows/temp/_vcrun2022/win64/a12: WARNING; possible 10368 extra bytes at end of file.
Executing wine vc_redist.x64.exe /q
Using winetricks 20260125 - sha256sum: 7fa92e6fd8594699ab0d2ffc32d5e20398b38718f2f26081eb782cb69824faae with wine-11.0 (Staging) and WINEARCH=win64

The Fedora Winetricks package depends on wine-common, and every WineHQ package conflicts with it. On a WineHQ machine sudo dnf install winetricks fails the same way the Wine swap did, and --allowerasing would remove WineHQ to make room:

  - installed package winehq-devel-1:11.19-1.1.x86_64 conflicts with wine-common provided by wine-common-11.0-3.fc44.noarch from fedora
  - package winetricks-20260125-1.fc44.noarch from fedora requires wine-common, but none of the providers can be installed

Use the upstream script instead. It needs cabextract, which the Fedora Winetricks package normally pulls in:

sudo dnf install -y cabextract
mkdir -p ~/.local/bin && cd ~/.local/bin
curl -LO https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks
chmod +x winetricks

Fedora puts ~/.local/bin on the default PATH, so winetricks works from any directory. With the WineHQ devel build, winetricks -q vcrun2022 from the script installed both the 32-bit and 64-bit runtimes in 39 seconds.

Confirm what a prefix has received so far:

winetricks list-installed

Keep one prefix per demanding program with WINEPREFIX=~/.wine-appname. A runtime one program needs can break another, and deleting a separate prefix is a clean rollback.

Remove Wine and every leftover

Removing the packages leaves the prefix, the Winetricks cache and the menu entries behind. Remove the packages first. Dnf5 drops the unused dependencies with them, 220 packages and 2 GiB on our Fedora 45 machine:

sudo dnf remove -y wine winetricks

For the WineHQ build, remove winehq-devel (or winehq-staging), delete /etc/yum.repos.d/winehq.repo, and delete ~/.local/bin/winetricks and the Mono MSI in ~/.cache/wine if you used them. Then clear the per-user files. The 7-Zip installs alone created five desktop-directory and menu files plus file associations:

rm -rf ~/.wine ~/.cache/winetricks ~/.local/share/applications/wine
rm -f ~/.local/share/applications/wine-extension-*.desktop
rm -f ~/.local/share/desktop-directories/wine-*.directory
rm -f ~/.config/menus/applications-merged/wine-*.menu
sudo rm -f /etc/modules-load.d/ntsync.conf

After that, rpm -qa 'wine*' returns nothing and GNOME no longer lists the Windows programs. If you removed Wine because a program misbehaved, try a fresh prefix before reinstalling anything, because a damaged prefix is the usual cause. On a new machine, the post-install checklist for Fedora 45 covers RPM Fusion and the codecs most Windows media software needs.