How to Install Kodi Media Center on Fedora 45 / 44

Flip the wrong remote-control toggle in Kodi and any device on your LAN can read its web server password from port 9090. We proved that on a fresh install while refreshing this guide, which is why the remote-control section below is longer than the install itself. Getting Kodi onto Fedora is easy, because both RPM Fusion and Flathub carry it, but the two sources give you different releases.

Original content from computingforgeeks.com - post 18923

This guide shows you how to install Kodi on Fedora from RPM Fusion or as a Flatpak, how to pin the 21.3 build on Fedora 44, and how to enable the web remote without leaving an unauthenticated port open. It ends with a systemd unit that boots an HTPC straight into Kodi, past the console clash that stops it on Fedora 45. All of it was tested in October 2026 on Fedora 45 and Fedora 44 with SELinux enforcing, so no step turns it off.

Which Kodi build each source installs on Fedora

RPM Fusion has moved Kodi to the 22 “Piers” line, while Flathub still ships the 21.3 “Omega” stable release. That choice decides how many of your existing add-ons keep working, so make it before you install anything. These are the builds each source served in our lab:

Source	Fedora 45	Fedora 44	Runtime notes
RPM Fusion kodi (default)	22.0-0.8rc1 (release candidate 1)	22.0-0.6b2 from rpmfusion-free-updates	Links Fedora’s ffmpeg-free libraries, which have no native H.264 or HEVC decoder until you swap in RPM Fusion’s ffmpeg
RPM Fusion, updates excluded	not available	21.3-7 from rpmfusion-free	Same packaging, older add-on API
Flathub tv.kodi.Kodi	21.3-Omega	21.3-Omega	Bundles its own full FFmpeg build; org.freedesktop.Platform 24.08 runtime, which Flatpak reports as end-of-life

The release candidate ran fine in our tests, but add-ons built for the Omega API are the ones most likely to break, because Kodi 22 moves the add-on interface forward. Pick the source by what the box is for:

• A dedicated HTPC runs the RPM, which ships the login sessions and firewalld services used below.
• A desktop whose add-ons must keep working runs the Flatpak, which is on 21.3 Omega.
• A Fedora 44 box that wants the RPM without the 22 line pins Kodi to 21.3.

Don’t mix the two on one account. The RPM and the Flatpak keep separate profiles (~/.kodi against ~/.var/app/tv.kodi.Kodi), so a library you build in one is invisible to the other, and each one carries its own copy of the remote-control settings. That doubles what you have to audit, so pick one source per machine and remove the other.

Prerequisites

Kodi is a desktop application, so plan the machine around the display and storage, not the CPU. Check these before you start:

• The machine runs Fedora 45 or Fedora 44 Workstation, a spin, or a minimal install you will run Kodi on directly.
• Your account has sudo rights.
• The GPU has a working OpenGL or GLES driver. Mesa covers Intel and AMD; NVIDIA needs the proprietary driver from RPM Fusion for hardware decode.
• About 800 MB of free disk for the RPM install (the transaction reported 770 MiB) or about 2.2 GB for the Flatpak, because the app (577.5 MB) brings the Platform runtime (691.3 MB) and two GL runtimes (about 465 MB each).

RPM Fusion repositories on Fedora 45 and 44

Kodi is not in Fedora’s own repositories because of the codecs it links, so the RPM route starts with RPM Fusion. Install both release packages with dnf rather than rpm -Uvh, because Fedora 45’s rpm refuses a downloaded package whose key it has not imported yet:

sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

dnf5 prints “skipped OpenPGP checks for 2 packages from repository: @commandline”. That is expected: the signing keys are inside these two packages, and dnf imports them on the first install from the new repos. List the repos to confirm they are registered.

dnf repo list | grep -i rpmfusion

Fedora 44 shows the base and updates repos for both halves. Kodi only needs the free half, but the nonfree half is where NVIDIA drivers and hardware decoders live, so keep both.

rpmfusion-free            RPM Fusion for Fedora 44 - Free
rpmfusion-free-updates    RPM Fusion for Fedora 44 - Free - Updates
rpmfusion-nonfree         RPM Fusion for Fedora 44 - Nonfree
rpmfusion-nonfree-updates RPM Fusion for Fedora 44 - Nonfree - Updates

If your Fedora 45 list shows rpmfusion-free-updates-testing and rpmfusion-nonfree-updates-testing instead of the two updates repos, your installed release package points there, as it did on our Fedora 45 machine. Kodi comes from the base rpmfusion-free repo either way, so the install below is identical whichever pair you see. VA-API drivers and the rest of the codec stack are covered in the RPM Fusion and multimedia codecs guide for Fedora.

Install Kodi on Fedora from RPM Fusion

One package brings in the player, the Estuary skin, Python and the decoder libraries. On a minimal Fedora 45 install the transaction was 213 packages, 220 MiB to download and 770 MiB on disk; Fedora 44 pulled 224 packages for about the same size. Install it with dnf.

sudo dnf install kodi

Check which build landed before you add anything else. The version tells you which add-on API you are on, and binary add-ons built for the other line refuse to load, so this is the number to quote when an add-on fails.

rpm -q kodi
kodi --version

On Fedora 45 the package version carries rc1 and the banner says the same:

kodi-22.0-0.8rc1.fc45.x86_64
Kodi Media Center 22.0-RC1 (21.90.901) Git:20261014-nogitfound
Copyright (C) 2005-2021 Team Kodi - http://kodi.tv

Launch Kodi from the application grid or run kodi from a desktop terminal. The first start creates ~/.kodi/userdata/ and opens the Estuary home screen with an empty library and an “Enter files section” button:

The package also installs two login sessions, /usr/share/xsessions/kodi.desktop and /usr/share/wayland-sessions/kodi-gbm.desktop, so GDM or SDDM can offer “Kodi” next to your desktop. The kiosk unit later in this guide uses the same kodi-standalone wrapper without a display manager.

Swap in the full FFmpeg before you play anything

Installing the kodi RPM does not give you a native H.264 or HEVC decoder. RPM Fusion builds Kodi against the system FFmpeg, and on a stock Fedora that is ffmpeg-free, which has those decoders compiled out and handles H.264 only through Cisco’s OpenH264. Ask rpm which package owns the library Kodi links (the glob matches .so.63 on Fedora 45 and .so.62 on Fedora 44):

rpm -qf /usr/lib64/libavcodec.so.6?

On Fedora 45 it is the free build (Fedora 44 reported libavcodec-free-8.1.3-1.fc44):

libavcodec-free-9.0.2-2.fc45.x86_64

With the ffmpeg-free command installed, you can list what that library decodes. Filter the list down to the formats a media library depends on:

ffmpeg -hide_banner -decoders 2>/dev/null | grep -E ' (h264|hevc|vc1|eac3|libopenh264|libdav1d|av1)( |$)'

Of those formats, only AV1 and the OpenH264 wrapper are there, so HEVC files, VC-1 discs and E-AC-3 audio tracks fail to decode inside Kodi:

 V..... libdav1d             dav1d AV1 decoder by VideoLAN (codec av1)
 V....D av1                  Alliance for Open Media AV1
 V....D libopenh264          OpenH264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (codec h264)

Replace the free build with RPM Fusion’s full one. --allowerasing lets dnf remove the -free libraries in the same transaction, and Kodi stays installed because the new ffmpeg-libs package provides the same sonames:

sudo dnf swap ffmpeg-free ffmpeg --allowerasing

The swap worked on both releases whether or not the ffmpeg-free command was installed, because --allowerasing also replaces the bare libavcodec-free libraries that Kodi pulled in. Afterwards rpm -qf reports ffmpeg-libs-9.0.2-1.fc45 on Fedora 45 (ffmpeg-libs-8.1.3-1.fc44 on 44), and the same filtered decoder list gains the native entries Kodi needs:

 V..... libdav1d             dav1d AV1 decoder by VideoLAN (codec av1)
 V....D av1                  Alliance for Open Media AV1
 VFS..D h264                 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
 V....D libopenh264          OpenH264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (codec h264)
 VFS..D hevc                 HEVC (High Efficiency Video Coding)
 V....D vc1                  SMPTE VC-1
 A....D eac3                 ATSC A/52B (AC-3, E-AC-3)

The Flatpak does not need this step, because the Flathub manifest compiles its own full FFmpeg into the app. Both decoder lists come from the ffmpeg command, which reads the same library Kodi loads, and the swap installs that command if you did not have it. The swap is RPM Fusion’s own documented fix, listed on its multimedia howto.

Stay on Kodi 21.3 on Fedora 44

Fedora 44’s base rpmfusion-free repo still holds kodi 21.3-7, and only the updates repo carries the 22 build. Excluding Kodi packages from that one repo pins you to 21.3 across upgrades, add-ons included, because the kodi* pattern also matches every kodi- add-on package. The config-manager subcommand comes from dnf5-plugins, so install that first if dnf says the command is unknown:

sudo dnf install dnf5-plugins
sudo dnf config-manager setopt rpmfusion-free-updates.excludepkgs='kodi*'

If Kodi 22 is already installed, remove it with sudo dnf remove kodi and install again; dnf then resolves 21.3 from the base repo. The override lands in /etc/dnf/repos.override.d/99-config_manager.repo, and a full sudo dnf upgrade --refresh afterwards reported “Nothing to do” instead of pulling 22 back in:

Remove the pin with sudo dnf config-manager unsetopt rpmfusion-free-updates.excludepkgs once your add-ons support Kodi 22. Fedora 45 has no 21.x RPM at all, so on 45 the Flatpak is the only way to stay on Omega.

Add-on packages that still exist

Binary add-ons (stream decoders, PVR clients, visualizations) have to match Kodi’s ABI, so take them from the same repo as Kodi rather than from the in-app repository. The add-on line older guides used, including the earlier version of this one, now fails on Fedora 45 because kodi-screensaver-greynetic is gone. This set resolved cleanly on both releases:

sudo dnf install kodi-inputstream-adaptive kodi-inputstream-rtmp kodi-pvr-iptvsimple kodi-pvr-hts

Each package has a narrow job, so install only the ones you use.

Package	What it adds	Fedora 45 build
kodi-inputstream-adaptive	HLS, MPEG-DASH and Smooth Streaming playback for streaming add-ons	22.3.19
kodi-inputstream-rtmp	RTMP streams	22.0.0
kodi-pvr-iptvsimple	IPTV from M3U playlists with XMLTV guide data	22.6.4
kodi-pvr-hts	Tvheadend client for DVB tuners	22.9.1
kodi-pvr-vdr-vnsi	VDR backend client	22.3.1
kodi-visualization-spectrum	Music visualization	22.1.0
kodi-firewalld	firewalld service files for ports 8080, 9090 and 9777	22.0
kodi-eventclients	kodi-send and other EventServer clients	22.0

Script and plugin add-ons (YouTube, Jellyfin, subtitle scrapers) come from inside Kodi: Settings, Add-ons, Install from repository, Kodi Add-on repository. Stay on the official repository. Third-party repositories run Python inside Kodi’s process with the same rights as your user, and Kodi does not sandbox them.

Kodi as a Flatpak from Flathub

The Flathub build is published by Team Kodi and marked verified for kodi.tv, so it’s the official package rather than a community repack. It needs no RPM Fusion, which makes it the cleaner choice on a desktop where Kodi is one app among many. If flatpak remotes does not list flathub, add it first (the Flatpak and Flathub setup guide for Fedora covers the filtered Fedora remote too):

sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
sudo flatpak install flathub tv.kodi.Kodi

The install took 4 minutes 38 seconds on our lab link and pulled the app plus five runtime pieces. Flatpak printed this notice for the Platform, Locale and GL runtimes, and you should read it rather than scroll past:

Info: org.freedesktop.Platform is end-of-life, with reason: org.freedesktop.Platform 24.08 is no longer receiving fixes and security updates. Please update to a supported runtime version.

The Kodi app itself was updated on 2026-09-28, but the runtime underneath it gets no more security fixes. That matters on a box that plays files from the internet, because the image and font libraries in that runtime parse untrusted input. The RPM links the system FFmpeg and image libraries, which Fedora and RPM Fusion keep patching. Check what the sandbox allows.

flatpak info --show-permissions tv.kodi.Kodi

The sandbox is loose by design, since a media center needs remotes, network shares and removable drives:

[Context]
shared=ipc;network;
sockets=fallback-x11;pulseaudio;wayland;
devices=all;
features=bluetooth;
filesystems=/mnt;xdg-pictures;xdg-videos;/run/udev:ro;/run/lirc;xdg-music;/media;/run/media;

[Session Bus Policy]
org.freedesktop.ScreenSaver=talk

[System Bus Policy]
org.freedesktop.Avahi=talk
org.freedesktop.login1=talk
org.freedesktop.UPower=talk
org.freedesktop.UDisks2=talk

Two things in that list matter. devices=all and network mean the sandbox does little to contain a malicious add-on. And the filesystem list does not include your home directory, so a library in ~/Media is invisible to Kodi. Grant that folder read-only rather than giving it home:

flatpak override --user --filesystem=~/Media:ro tv.kodi.Kodi

After the override Kodi listed the files in ~/Media, and a write test from inside the sandbox failed with “Read-only file system”, which is what you want for a library Kodi should never modify. The xdg-videos entry only works when XDG user folders exist: on our minimal install ~/Videos stayed invisible until xdg-user-dirs-update wrote ~/.config/user-dirs.dirs. Workstation creates that file at first login.

Media sources and the library

Kodi builds its library from sources you add under Videos, Files, Add videos. A source can be a local folder or a network share (SMB, NFS, WebDAV), and Kodi mounts network shares itself, so nothing has to be mounted on the host. When you add a source, set its content type (Movies, TV shows) so the right scraper runs. Kodi keeps share credentials in its own profile, so give it a read-only share account that cannot write to the library.

Decoding is only as good as the FFmpeg Kodi loads, so on the RPM finish the swap above before you blame a file. For quick playback outside the library, VLC on Fedora covers the same formats, and the FFmpeg guide for Fedora covers the RPM Fusion and ffmpeg-free split in more depth.

What Kodi listens on by default

Before you turn any remote on, look at what a fresh Kodi already exposes. We ran the RPM build with nothing changed and listed its sockets:

sudo ss -tulnp | grep kodi

JSON-RPC and the EventServer bind to loopback only, but one UDP port is open on every interface:

udp   UNCONN 0      0          127.0.0.1:9777      0.0.0.0:*    users:(("kodi.bin",pid=7903,fd=47))
udp   UNCONN 18880  0            0.0.0.0:3702      0.0.0.0:*    users:(("kodi.bin",pid=7903,fd=45))
tcp   LISTEN 0      10         127.0.0.1:9090      0.0.0.0:*    users:(("kodi.bin",pid=7903,fd=50))
tcp   LISTEN 0      10             [::1]:9090         [::]:*    users:(("kodi.bin",pid=7903,fd=44))

UDP 3702 is WS-Discovery, which Kodi’s SMB client uses to find Windows shares. It is controlled by services.wsdiscovery, which defaults to on in guisettings.xml. The same file shows the defaults for every remote service, and the one to notice is the empty web server password:

grep -E 'services\.(webserver|esenabled|esallinterfaces)' ~/.kodi/userdata/guisettings.xml

Out of the default list, these lines decide who can drive the box:

    <setting id="services.webserver" default="true">false</setting>
    <setting id="services.webserverport" default="true">8080</setting>
    <setting id="services.webserverauthentication" default="true">true</setting>
    <setting id="services.webserverusername" default="true">kodi</setting>
    <setting id="services.webserverpassword" default="true" />
    <setting id="services.webserverssl" default="true">false</setting>
    <setting id="services.esenabled" default="true">true</setting>
    <setting id="services.esallinterfaces" default="true">false</setting>

With the defaults, then, nothing on the LAN can control Kodi. Every remote you enable from here widens that, and the two toggles in Settings, Services, Control widen it very differently.

The web remote on port 8080

“Allow remote control via HTTP” starts the web server, which serves the browser interface and phone remotes such as Kore. Set the password first. If you flip the toggle while the password field is empty, Kodi refuses with this dialog and leaves the server off:

With a password set, the toggle shows a second warning that spells out the risk in Kodi’s own words: anyone with access to the web interface controls the application and the device. Answer Yes only on a network you trust:

The server binds to all interfaces the moment you accept; there is no setting that limits it to one network. Store the password you chose in a variable so the checks below can use it:

export KODI_PASS='Str0ng-Remote-Pass'

Prove that authentication holds by sending the same JSON-RPC ping without and with credentials:

curl -s -o /dev/null -w ' HTTP %{http_code}\n' -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","method":"JSONRPC.Ping","id":1}' http://localhost:8080/jsonrpc
curl -s -w ' HTTP %{http_code}\n' -u "kodi:${KODI_PASS}" -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","method":"JSONRPC.Ping","id":1}' http://localhost:8080/jsonrpc

The anonymous request gets 401 and the authenticated one gets a pong, which is the behaviour you want on port 8080:

 HTTP 401
{"id":1,"jsonrpc":"2.0","result":"pong"} HTTP 200

Leave “Enable SSL” off only if the box never leaves your LAN. The web server sends basic auth, so the password crosses the network base64-encoded on plain HTTP.

The unauthenticated control port on 9090

“Allow remote control from applications on other systems” is the dangerous one, and Kodi says so. It moves JSON-RPC over raw TCP (port 9090) and the EventServer (UDP 9777) from loopback to every interface, and neither of those transports has a login:

With both toggles on, the socket list shows what changed. 9090 and 9777 now sit on all addresses next to the web server:

We then connected to 9090 on the machine’s LAN address from a script with no credentials and asked Kodi for its settings. It answered every call, including the web server password set a minute earlier. Run the same check against your own box from another machine on the network, replacing the address:

python3 -c "import socket; s=socket.create_connection(('10.0.1.50',9090),timeout=5); s.sendall(b'{\"jsonrpc\":\"2.0\",\"method\":\"Settings.GetSettingValue\",\"params\":{\"setting\":\"services.webserverpassword\"},\"id\":3}'); print(s.recv(4096).decode())"

A box that exposes 9090 hands the password straight back. Nothing in the request identifies the caller, so any device on the network gets the same answer.

{"id":3,"jsonrpc":"2.0","result":{"value":"Str0ng-Remote-Pass"}}

So the 8080 password protects nothing once 9090 is reachable. Kodi’s JSON-RPC documentation describes the raw TCP transport as the one that adds live notifications on top of plain responses, which HTTP already provides behind the password. Keep “applications on other systems” off unless a specific client needs it, and if you do enable it, the firewall becomes your only control. Connection refused on 9090 from another machine is the result you want.

Firewall rules scoped to one client

Older guides open 8080 and 9090 to the whole zone with --add-port. That re-creates the exposure above for every host that can reach the box. The kodi-firewalld package ships named firewalld services, so a rule can name the Kodi service and the one client allowed to use it:

• kodi-http opens 8080/tcp, the password-protected web remote.
• kodi-jsonrpc opens 9090/tcp, which has no login.
• kodi-eventserver opens 9777/udp, which has no login either.

A minimal install may not run firewalld at all (our cloud-image lab machines did not), so install it first. Its public zone allows only the ssh service on port 22, so if your sshd listens on another port, open that port before you start firewalld over SSH or you lock yourself out:

sudo dnf install firewalld kodi-firewalld
sudo systemctl enable --now firewalld
firewall-cmd --get-active-zones

The rules below go into public. If your interface is listed under any other zone (Workstation uses FedoraWorkstation, Server uses FedoraServer), move the connection to public first with the nmcli command shown further down, otherwise the rule is stored but never matches. Then allow only kodi-http, and only from your LAN subnet:

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="10.0.1.0/24" service name="kodi-http" accept'
sudo firewall-cmd --reload

Narrow the source to your phone’s reserved address (/32) if your router hands out fixed leases. In the lab the rule allowed one host: that host got a pong on 8080 and “Could not connect to server” on 9090, while a machine outside the rule could not reach 8080 at all. Confirm the rule is active.

sudo firewall-cmd --zone=public --list-rich-rules

There is a catch on Fedora Workstation. Its default FedoraWorkstation zone already allows every port from 1025 to 65535, so 8080 and 9090 are open to the LAN before you add anything:

sudo firewall-cmd --info-zone=FedoraWorkstation | grep -E 'services|ports'

The zone definition shows the range.

  services: dhcpv6-client samba-client ssh
  ports: 1025-65535/udp 1025-65535/tcp
  forward-ports:
  source-ports: 

On Workstation the rich rule adds nothing, and Kodi’s own settings are what stand between the LAN and the box: a password on 8080 and “other systems” off. To make the firewall count, move the HTPC’s connection to the public zone, which allows only ssh, mdns and dhcpv6-client, and keep the rich rule there. NetworkManager owns the zone setting, so change it on the connection (replace the name with yours from nmcli connection show --active):

sudo nmcli connection modify "Wired connection 1" connection.zone public
sudo nmcli connection up "Wired connection 1"
firewall-cmd --get-active-zones

The last command should list your interface under public. In the lab, firewall-cmd --get-zone-of-interface followed each nmcli change, switching between FedoraWorkstation and public. The firewalld guide for Fedora walks through zones and rich rules in detail.

Boot straight into Kodi on a dedicated HTPC

A box that exists only to run Kodi does not need GNOME. A systemd unit can start kodi-standalone on tty1 as an unprivileged user and give it the display through the kernel’s DRM interface (GBM). This assumes the machine boots to multi-user.target with no display manager, which is how both lab machines ran; on a Workstation install, sudo systemctl set-default multi-user.target takes GDM out of the boot so nothing else competes for the screen. Create a system user with no login password:

sudo useradd --system --create-home --home-dir /var/lib/kodi --user-group kodi

Open a new unit file in vim.

sudo vim /etc/systemd/system/kodi.service

Paste this unit. It is the exact file that ran on both lab machines:

[Unit]
Description=Kodi standalone (GBM)
After=remote-fs.target systemd-user-sessions.service network-online.target sound.target
Wants=network-online.target
Conflicts=[email protected] [email protected]

[Service]
User=kodi
Group=kodi
SupplementaryGroups=video render input audio
PAMName=login
TTYPath=/dev/tty1
StandardInput=tty
StandardOutput=journal
ExecStart=/usr/bin/kodi-standalone --windowing=gbm
Restart=on-abort

[Install]
WantedBy=multi-user.target

The Conflicts= line is the Fedora 45 part. Fedora 45 runs kmscon as the console on tty1 ([email protected]), and kmscon keeps the DRM device open. Without it in Conflicts=, Kodi starts, logs “Failed to authorize drm magic: Permission denied” and never takes the screen. On Fedora 44 that unit does not exist and the line is harmless. PAMName=login gives Kodi a logind session on seat0, which is what lets an unprivileged user own the display.

Confirm you can SSH into the box before the next step. With Kodi on tty1 there is no local text console, and if Kodi fails to take the screen you are left with a blank display; from SSH, sudo systemctl disable --now kodi.service undoes it. Enable it and reboot.

sudo systemctl daemon-reload
sudo systemctl enable kodi.service
sudo systemctl reboot

After the reboot, confirm that the kodi user, not kmscon, holds the display device. The wildcard matters: on machines with a simple framebuffer or two GPUs the display may be card1.

systemctl is-active kodi.service
sudo fuser -v /dev/dri/card*

Both lab machines came back with Kodi on the card and the service active. If kmscon or a display manager also appears in the fuser list, Kodi lost the race for the display and is running without a screen.

active
                     USER        PID ACCESS COMMAND
/dev/dri/card0:      kodi        944 F...m kodi.bin

Kodi’s profile for this user lives in /var/lib/kodi/.kodi, separate from your own account, so the remote-control settings above apply again there.

To get the console back, disable the unit and, on Fedora 45, start kmscon again, because the conflict stopped it and disabling Kodi does not bring it back on its own:

sudo systemctl disable --now kodi.service
sudo systemctl start [email protected]

On Fedora 44 the getty on tty1 stayed inactive right after disable --now, so reboot instead. After a reboot both lab machines were back on their normal console: kmscon on Fedora 45, getty on Fedora 44.

Updates and removal

The RPM updates with the rest of the system, and RPM Fusion rebuilds Kodi and its binary add-ons together, so upgrade them in one transaction to keep the ABI matched:

sudo dnf upgrade --refresh kodi 'kodi-*'

Flatpak updates arrive through flatpak update or GNOME Software. Removing the RPM is one command; on Fedora 45 it took out 90 packages, because dnf5 also removes dependencies nothing else needs:

sudo dnf remove kodi 'kodi-*'

Package removal leaves your profile behind. Delete ~/.kodi (and /var/lib/kodi plus the kodi user on an HTPC) only if you no longer want the library, the saved share passwords or the add-ons. For the Flatpak, uninstall the app, remove the runtimes nothing else uses, then delete your profile by hand:

sudo flatpak uninstall tv.kodi.Kodi
sudo flatpak uninstall --unused
rm -rf ~/.var/app/tv.kodi.Kodi
flatpak override --user --reset tv.kodi.Kodi

The last line clears the ~/Media override from earlier, which lives in ~/.local/share/flatpak/overrides/ and survives everything else. The rm is not optional if you want the data gone. In the lab, sudo flatpak uninstall --delete-data removed the app but left ~/.var/app/tv.kodi.Kodi in place, because under sudo it cleans root’s home rather than yours. Run the two flatpak commands with sudo over SSH: as a normal user with no polkit agent to ask for a password, --unused failed with “Flatpak system operation Uninstall not allowed for user”. In a desktop session polkit prompts you instead.

Errors we hit and their fixes

Each of these came up during the Fedora 45 and Fedora 44 runs. The exact message is the heading so you can match it.

No match for argument: kodi-screensaver-greynetic

dnf5 aborts the whole transaction when one package in the list does not exist, so a single stale name blocks every add-on in the same command:

Failed to resolve the transaction:
No match for argument: kodi-screensaver-greynetic
You can try to add to command line:
  --skip-unavailable to skip unavailable packages

Drop the name and use the add-on line above. Before adding any package, check that it exists with dnf repoquery 'kodi-*', which lists every Kodi package your repos offer.

If web server authentication is enabled, a password must be entered as well

Kodi shows this when “Allow remote control via HTTP” is switched on while the password field is empty, and it leaves the web server off. Go to Settings, Services, Control, set the password, then turn the toggle on. Do not work around it by disabling web server authentication: that leaves 8080 open to anyone who can reach it.

Failed to authorize drm magic: Permission denied

This is in /var/lib/kodi/.kodi/temp/kodi.log when the kiosk unit starts on Fedora 45 without [email protected] in Conflicts=. The next log line ends in “failed to initialize Atomic DRM”, and sudo fuser -v /dev/dri/card* shows both kmscon (as root) and kodi.bin on the device. Add the unit to Conflicts=, run sudo systemctl daemon-reload and restart the service.

Flatpak Kodi cannot see the media folder

From inside the sandbox, a folder in your home directory does not exist. Listing ~/Media through the Flatpak returned “No such file or directory” even though the files were there. Grant the folder read-only with flatpak override --user --filesystem=~/Media:ro tv.kodi.Kodi, or move the library under /mnt or /media, which the Flatpak already reads.

Audit checklist for a Kodi box on your network

Run through this after the install and again after any change in Settings, Services. Every item is something you can check from a shell, and each one closes a path we used in the lab:

1. sudo ss -tulnp | grep kodi shows 9090 and 9777 on 127.0.0.1 only, unless a client you named needs them.
2. An anonymous curl to port 8080 returns HTTP 401.
3. The web server password is not the one you use anywhere else, since anything that reaches 9090 can read it.
4. Port 9090 refuses connections from another machine on the LAN.
5. The interface is in a zone without the 1025-65535 range, and sudo firewall-cmd --zone=public --list-rich-rules names the clients allowed to reach kodi-http.
6. The router does not forward 8080, 9090 or 9777, so none of them is reachable from the internet.
7. Only the official Kodi add-on repository is enabled under Settings, Add-ons.
8. On an HTPC, systemctl show -p User kodi.service prints User=kodi, never root.

If item 1 or 4 fails, fix it before anything else: an open 9090 undoes every other control on the list. For the rest of a fresh desktop, the post-install checklist for Fedora 45 Workstation covers updates, codecs and backups.