Learn › RHCSA (EX200) › Deploy, Configure, Maintain
flatpak - a hands-on Linux lab on a real virtual machine.
Install and manage desktop applications delivered as Flatpaks on RHEL 10, the ones dnf cannot find. Confirm the tool with flatpak --version, see catalogs with flatpak remotes, add one with flatpak remote-add (--user for one user with no root, --system for all users as root), then flatpak install an app by its reverse-DNS application ID like org.gnome.Clocks in the matching scope, verify with flatpak list --app, and run, update, or uninstall it. The scope you add a remote in is the scope you must install in. Serves EX200 deploy-configure: manage Flatpak applications and remotes.
A task hands you a machine and one line: install the Clocks application for the desktop user. You do what you always do. You reach for dnf install gnome-clocks, and dnf tells you there is no such package. You try a couple of guesses at the name. Nothing. The application exists, the desktop shows it in the software catalog, but the package manager you have leaned on for years cannot see it.
That is because on RHEL 10, a growing set of desktop applications no longer ship as RPMs at all. They ship as Flatpaks: self-contained application bundles that live outside the RPM world, managed by a completely separate tool called flatpak. If a task asks you to install a graphical app and dnf comes up empty, this is why, and flatpak is the tool that finishes the job. This lesson takes you from checking the tool is present, to finding where apps come from, to installing, running, and removing one.
The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs come from a real RHEL 10 machine (AlmaLinux 10.2). On that machine no remotes are configured and no Flatpak apps are installed yet, so several commands correctly print nothing. That silence is real output, not a fault. What is stable everywhere is the SHAPE of each command, and the shapes are exactly what the exam grades.
Flatpak is a packaging and distribution system for desktop applications. Instead of splitting an app across dozens of system RPMs and shared libraries, Flatpak bundles the application together with the libraries it needs into one sandboxed package. That bundle runs the same way on any Linux distribution, isolated from the rest of the system.
The real-world analogy is a food truck versus a restaurant kitchen. An RPM is a dish cooked in the house kitchen, depending on the house ovens, pans, and pantry being exactly right. A Flatpak is a food truck: it brings its own kitchen with it, parks anywhere, and serves the same meal regardless of what the host building has. The tool you drive it with is the flatpak command.
You reach for flatpak whenever a graphical application is not available as an RPM, which on RHEL 10 is increasingly common for end-user desktop apps like Clocks, Calculator, and image viewers. Red Hat is steadily moving these out of the base RPM set and into Flatpak, so a modern RHCSA task that says install a desktop application often means install a Flatpak, not run dnf.
The workflow is always the same three ideas. Apps come from a remote, a catalog of Flatpaks the machine can pull from. You install an app from a remote. Then you run, update, or uninstall it. Learn those four verbs and you can handle any Flatpak task the exam throws at you.
Before you manage anything, confirm the flatpak command is present and see which version you are working with. The simplest invocation is flatpak --version. It prints one line naming the tool and its version number, which is also a quick way to prove the tool is installed at all.
Before you run it, know what success looks like: a single line beginning with the word Flatpak. Check the version:
flatpak --version
prompt: [root@servera ~]# answer: flatpak --version output: Flatpak 1.16.0 hint: Ask the tool to print its own version: flatpak --version
The single line Flatpak 1.16.0 confirms two things at once: the flatpak command exists on this machine, and it is version 1.16.0. If the tool were missing you would instead see a command not found error, which on the exam is your cue to dnf install flatpak first. Your exact version number may read differently on your machine; what matters is that a version line prints instead of an error.
The version number will differ across machines and image versions. Do not memorize 1.16.0. Read the shape: the word Flatpak followed by a version means the tool is installed and ready.
A remote is a named catalog of Flatpak applications that this machine is allowed to install from, the way a dnf repository is a named catalog of RPMs. Before you can install any app you need a remote to install it from. The command flatpak remotes lists every remote currently configured, one per line.
On this fresh machine no remote has been added yet, so the list is empty and the command prints nothing at all. Predict that before you run it: no remotes configured means no output. List the remotes:
flatpak remotes
prompt: [root@servera ~]# answer: flatpak remotes output: hint: Ask flatpak to list its catalogs, the remotes: flatpak remotes
No output, and this time silence is the whole answer: there are zero remotes configured on this machine, so there is nothing to list. That is exactly what an empty Flatpak system looks like. It also tells you the first move on any install task: if flatpak remotes is empty, you cannot install anything until you add a remote. On the exam the remote and its address are provided to you, and adding it is the next step.
On a machine where a remote is already configured, flatpak remotes prints a table with the remote name in the first column, for example flathub. Here it is blank only because none has been added. Your machine may show one or more rows depending on how it was set up.
To give the machine a place to install from, you add a remote with flatpak remote-add. You hand it a name you choose and the address of a .flatpakrepo file that describes the catalog. The exam provides both the name and the address, so you type them exactly as given.
One decision matters here, and it is the classic RHCSA fork: who is this remote for? The --user flag adds the remote for just the current user. It writes into that user's home directory and needs no root. The --system flag adds it for every user on the machine and requires root. The exam task tells you which. Add the provided remote for the current user, calling it labhub:
flatpak remote-add --user labhub http://content.lab.example.net/flathub.flatpakrepo
prompt: [student@servera ~]$ answer: flatpak remote-add --user labhub http://content.lab.example.net/flathub.flatpakrepo output: hint: The verb is remote-add, then the scope flag, then a name and the repo URL: flatpak remote-add --user labhub http://content.lab.example.net/flathub.flatpakrepo
Silence again means success: flatpak remote-add prints nothing when it works, and the remote labhub is now a catalog the current user can install from. Run flatpak remotes after this and labhub appears in the list. The --user scope means this remote and anything you install through it live under your own home directory, which is why root was not needed. Swap --user for --system and the same remote is available to everyone, but you must be root to add it.
--user and --system are two separate worlds, and mixing them is the classic Flatpak trap. A remote added with --user cannot be used to install with --system, and the reverse is also true. If you add the remote as --user but then run flatpak install --system, the install fails because that scope has never heard of the remote. Keep the scope consistent: whatever scope you added the remote in, install the app in the same scope.
With a remote in place you install an application by name. The command is flatpak install, the scope flag that matches your remote, the remote name, and the application's ID. Flatpak identifies apps by a reverse-DNS application ID, not a short package name. Clocks is not gnome-clocks; it is org.gnome.Clocks. Calculator is org.gnome.Calculator. This naming is why dnf install gnome-clocks failed at the top of the lesson.
Install Clocks from the labhub remote, in the same --user scope you added the remote in:
flatpak install --user labhub org.gnome.Clocks
prompt: [student@servera ~]$ answer: flatpak install --user labhub org.gnome.Clocks output: hint: The verb is install, matching the scope you used for the remote, then the remote name and the app ID: flatpak install --user labhub org.gnome.Clocks
On a live install, Flatpak would print the app and its runtime, ask you to confirm, then download. In this sandbox no output shows because the remote is not reachable here, but the command SHAPE is the exam answer: flatpak install, the scope, the remote, the app ID. The application ID org.gnome.Clocks is the piece people miss. When a task names an app, it gives you the reverse-DNS ID to use, and you type it exactly, capital C and all.
After installing, confirm the app is really there with flatpak list --app. Plain flatpak list shows both applications and the runtimes they depend on, which is noisy; adding --app filters the list down to just the applications you actually installed. Each row names one installed app and its application ID.
On this machine nothing has been installed, so the filtered list is empty and prints nothing. List the installed applications:
flatpak list --app
prompt: [root@servera ~]# answer: flatpak list --app output: hint: The verb is list, and the flag that hides runtimes and shows only apps is --app: flatpak list --app
Empty output, because no Flatpak apps are installed on this machine yet. After a real install, this same command would show one row per app with its name and its ID like org.gnome.Clocks. The --app flag is the useful part: without it, flatpak list also prints every runtime and library, and you have to hunt for your app in the clutter. flatpak list --app is the clean answer to which applications are installed.
Three verbs finish the toolkit, and all three key off the application ID. flatpak run org.gnome.Clocks launches the app by its ID. flatpak update pulls the latest version of installed apps; add an app ID to update just one. flatpak uninstall org.gnome.Clocks removes it. Notice the pattern: once an app is installed you refer to it by its ID alone, no remote name needed.
Launch the Clocks app you installed:
flatpak run org.gnome.Clocks
prompt: [student@servera ~]$ answer: flatpak run org.gnome.Clocks output: hint: The verb is run, followed by the application ID, no remote name needed: flatpak run org.gnome.Clocks
On a machine with Clocks installed and a graphical session, flatpak run org.gnome.Clocks opens the Clocks window. In this text sandbox there is nothing to display, so no output shows, but the shape is what you are drilling: flatpak run plus the application ID. To remove the app later, the mirror command is flatpak uninstall org.gnome.Clocks, and flatpak update keeps installed apps current. Run, update, uninstall: three verbs, all driven by the app ID.
Scaffolding off. No command is printed this time. You have every piece you need.
A task hands you a machine that already has the labhub remote configured for the current user. It tells you to install the Calculator application, whose application ID is org.gnome.Calculator, for that one user only. You are not root and you do not need to be. Which single command adds that application from the labhub remote, in the per-user scope, using the app ID exactly as given?
prompt: [student@servera ~]$ answer: flatpak install --user labhub org.gnome.Calculator output: hint: The verb is install, the per-user scope flag is --user, then the remote name labhub and the app ID: flatpak install --user labhub org.gnome.Calculator
flatpak install --user labhub org.gnome.Calculator is the answer. --user because the task said that one user only and you are not root. labhub is the remote to pull from. org.gnome.Calculator is the application ID, typed exactly. That four-part shape, install plus scope plus remote plus app ID, is the whole install pattern, and the scope flag must match the scope the remote was added in.
You earned this cheat sheet. Every row is a form you just ran or built:
The two things to burn in for the exam: applications are named by a reverse-DNS application ID like org.gnome.Clocks, not a short RPM name, and the scope must match. Whatever scope you added the remote in, --user or --system, install and manage the app in that same scope.
When a task says install a graphical application and dnf install cannot find the package, that is your signal to switch to Flatpak. The full exam pattern is always the same: confirm the remote with flatpak remotes, add it with flatpak remote-add if it is missing, then flatpak install the app ID in the matching scope, and verify with flatpak list --app.
The practice terminal walked you through the whole Flatpak loop. flatpak --version to confirm the tool, flatpak remotes to see the catalogs, flatpak remote-add to add one in the right scope, flatpak install to pull an app by its application ID, flatpak list --app to verify, and run, update, and uninstall to manage it after. Every one of those you typed yourself.
The deploy-configure module capstone, Operation Rollout, is where you run these against a real RHEL 10 machine. A full VM boots for you, with a remote the mission provides, and hands you objectives that use exactly what you practiced here. Add the remote in the scope the objective names, install the named application by its ID, and verify it. One difference from this lesson: the mission shows no commands. You read the objective, recall the flatpak remote-add and flatpak install forms, mind the scope, and type them. That recall is what makes it stick on exam day.
Finish the other deploy-configure lessons, then go roll out a real application.
Practice Flatpak Applications in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.