A Flatpak update stuck at one percentage can be waiting for a repository, downloading a runtime, or deploying files locally. Identify the installation scope and the exact ref that failed, preserve the first error, and compare the same transaction before deleting applications or adding a new remote.

Key Takeaways:

User and system installations can contain different copies of the same application.

A catalog result does not prove that the required runtime or application objects can download.

Preserve the remote, branch, architecture, and target commit when comparing paths.

Successful transfer and successful deployment are separate results; keep GPG verification enabled.

What is waiting when a Flatpak update stuck report appears?

Flatpak manages applications and runtimes through configured remotes. An update can involve the application, its runtime, and related extensions, so the last application name visible is not necessarily the object whose transfer failed.［1］ Start with the original terminal output instead of launching another all-app update. For failures across several unrelated tools, use the machine-level triage steps before narrowing the problem to this transaction.

Follow the first failed object

Read the transaction summary and the earliest error. Capture the ref, operation, origin, and whether progress was still changing. If the error is about a local lock, permissions, or space, a new route will not address that branch. If a runtime fails first, do not label the event as an application-server outage simply because you started an application update.

Evidence	Branch	What to preserve
Wrong or missing installation listed	Scope or application identity	User/system scope and complete ref
Remote metadata fails to load	Repository access	Remote name, authorized URL, first error
Runtime objects stop transferring	Dependency delivery	Runtime ref and target commit if available
Application objects stop transferring	Application delivery	App ref, branch, architecture, target commit
Download finishes but deployment fails	Local storage or deployment	Commit downloaded and local operation error

This classification is a working decision aid, not an assertion that every stall is network related. Keep the original application data intact while collecting it. Do not uninstall the application as an initial connectivity check.

Step 1: Which installation scope, remote, and ref are involved?

List installed objects and remotes before changing them. Flatpak supports both system-wide and per-user installations, and repositories also belong to an installation scope.［1］ Explicitly choose the scope shown for the affected copy; running a user command for a system installation can make an installed application appear absent.

Identify the original target

The following examples inspect a per-user installation. Use the corresponding --system commands when that is the original scope; do not switch scopes between attempts.

flatpak --version
flatpak --user remotes --show-details
flatpak --user list --columns=ref,origin
flatpak --user info APP_ID

Replace APP_ID with the installed application ID. Record its complete ref, including architecture and branch, its origin remote, installed commit, and runtime. Use the local command's help if your distribution provides an older Flatpak version with different display options. An unavailable optional column is not evidence of a network failure.

Close the affected application normally and save its documents before deployment. Avoid running a software-center update and a terminal update concurrently: two user interfaces can refer to the same installation. If another transaction owns it, wait for that transaction to finish or follow the administrator's supported cancellation procedure rather than deleting lock files.

For background on the format, see the Linux package distribution comparison. The question here is which existing Flatpak object failed, not whether another package format is inherently better.

Step 2: Does Flatpak remote connection fail before any download?

Inspect the configured remote's identity and compare it with the publisher's official installation instructions. A convenient local name such as flathub is not proof that its URL and trust configuration are correct. Do not replace an organization remote with a public repository simply to obtain a response.

Check metadata for the same object

Use flatpak --user remote-info REMOTE REF, replacing both values with the original remote name and full ref. This checks the selected object's remote information without intentionally updating the installed application. The command reference also documents inspecting the remote commit and previous versions.［2］ Keep the first connection error and the object it names.

A search may use already available catalog information. Likewise, opening the remote's website in a browser is not a check of the exact repository objects requested by Flatpak. Separate a catalog observation from a successful metadata request and from a completed transfer.

If the remote no longer supplies the branch, investigate its supported migration with the publisher. Do not repeatedly change VPN locations for a removed ref. If an administrator controls the remote, report the name, ref, and sanitized request failure; a managed repository may require its original organization network.

Step 3: Which ref caused Flatpak runtime download failed?

Compare the transaction entries and identify whether the first failed transfer is an application, runtime, or extension. Applications can require a runtime before installation completes.［1］ Record both the application ref and the runtime ref instead of assuming that success fetching one implies success fetching the other.

Preserve commit identity without forcing a downgrade

For a controlled comparison, obtain the target commit from remote information or the transaction output where available. Flatpak supports update --commit=COMMIT and inspecting a remote's commit history.［2］ Only use a commit that belongs to the existing trusted remote and selected ref, and confirm that it is the intended update target.

Do not take a random commit from a forum or force an old version to make the transfer smaller. If the remote moves to a newer commit between attempts, record the change and treat the retry as a changed target. Dependencies can also change, so a pinned application commit alone is not proof that every runtime and extension remained identical.

Check space on the installation filesystem and temporary storage, not merely in your home directory. If the error occurs during local deployment, preserve that stage and stop treating it as a transfer timeout. Never remove application data directories to free space without a separately planned backup and recovery process.

Step 4: Can the original transaction complete through another path?

Use a path comparison when the first error is a remote connection or interrupted object transfer and the existing remote remains trusted. Record the original scope, ref, remote, app target, and runtime target. Confirm no update is active, then retry one affected ref through the normal update command and review the proposed transaction before accepting it.

Change the path, then inspect each transaction entry

For a Debian/Ubuntu x64 workstation, use AethoVPN's official .deb package to compare the remote/object transfer over a nearby or home-country location allowed for your task. A Pro or Premium plan includes desktop use; enable global mode so this comparison covers the device's application traffic. Keep the existing remote and GPG settings, repeat the original scoped update, and compare the failed runtime entry as well as the application entry.

A different route cannot restore a removed ref, make an incompatible runtime suitable, or deploy into a full filesystem. If you were already using a VPN when the issue began, first try the approved direct baseline; if the new route makes the transaction worse, return to the original path. These are diagnosis steps, not a promise that a VPN fixes Flatpak.

When repository object delivery is the remaining branch, start the once-per-user 3-day Pro trial to perform that comparison on the same workstation.

Follow the tunnel checklist for Flatpak comparisons for recording network conditions. Check the Linux platform and setup requirements before using the product step: Snap and Flatpak may run on other distributions, but this installation path is limited to Debian/Ubuntu x64.

Do not interpret a fast second attempt as a clean speed measurement. Flatpak may have retained objects from the failed transfer, leaving less data to fetch. Note that cache difference and whether the remote target changed; the useful result is which requested objects transferred and deployed.

Step 5: Is the intended ref deployed and usable?

After a completed update, inspect the same scoped application information again. Compare the installed commit with the intended target and verify that the required runtime is present. flatpak list and flatpak info serve different views of installed objects; neither should be replaced by checking whether a storefront shows an “updated” badge.［1］［2］

Distinguish download-only results from application recovery

If you deliberately used a supported --no-deploy operation, downloading did not activate the new version. The command reference describes download and deployment controls separately.［2］ Label that result as transfer completion, then use the normal supported deployment workflow when appropriate rather than claiming the application is already updated.

Launch the application and open a saved noncritical document to check normal operation. A crash, missing portal permission, or unsupported feature after deployment belongs to application troubleshooting. Avoid changing sandbox permissions wholesale in response to a repository timeout; that changes a separate trust boundary.

If the transaction still fails, send the publisher or administrator the Flatpak version, scope, remote identity, app and runtime refs, installed and target commits, first error, and the path comparison. Redact private repository addresses, usernames, tokens, and personal paths. Keep GPG and certificate checks enabled; signature errors need trusted-source investigation, not another mirror chosen at random.

Summary

Identify the affected installation and full ref before retrying.
Separate catalog, metadata, runtime transfer, application transfer, and deployment.
Preserve the trusted remote and target commits where possible during a path comparison.
Verify the installed commit and normal application use; cached downloads are not performance evidence.

FAQ

Why does Flatpak search work while update stalls?

Search can rely on catalog information that is already available locally. Updating also needs the actual remote objects and dependencies, so check remote information and the failed transaction entry before assuming the application files are reachable.

Should I add Flathub again when a remote fails?

Inspect the existing remote in the correct installation scope first. Adding another repository can change trust, origins, and update sources; use the publisher's official procedure only when the configuration itself is confirmed wrong.

Why is a runtime downloading before the application?

The application may need that runtime to operate, so its transaction includes more than the application itself. Identify the failed runtime ref and keep it in the evidence, especially when application metadata loads successfully.

Is an application ID enough to compare two updates?

Record the scope, remote, branch, architecture, and commit as well. The same ID can refer to different installed copies or targets, and those differences can invalidate an apparent network comparison.

Does downloading with no deployment finish the update?

A download-only operation does not activate the new installed version. Verify deployment separately through the supported workflow and inspect the installed commit before reporting that the application has updated.

Can a VPN solve every Flatpak timeout?

A path change is useful only when evidence points to repository or object delivery. It does not resolve a missing ref, a signature rejection, full storage, or an incompatible runtime; preserve those failures rather than changing unrelated settings.

When should I stop retrying and seek help?

Stop when the trusted remote rejects signatures, the target ref has disappeared, or both authorized paths fail consistently. Provide sanitized refs and commit information so support can investigate the exact transaction without accessing your application data.

Sources

Flatpak documentation — Using Flatpak — https://docs.flatpak.org/en/latest/using-flatpak.html
Flatpak documentation — Flatpak Command Reference — https://docs.flatpak.org/en/latest/flatpak-command-reference.html

Sources checked 7 October 2026.

Flatpak Update Stuck: Check Remotes and Runtimes