How can I determine if DNF's metadata cache is stale for a newly added repository in Fedora?
0 reputation · 05 Feb 2023, 17:19 UTC
0 reputation · 05 Feb 2023, 17:19 UTC
After adding a new software repository on a Fedora system, DNF may continue to use outdated metadata from its local cache, causing dependency resolution errors or missed package updates. I need a way to assess whether the cached metadata for that repository is still fresh without clearing the entire cache or affecting other repositories. The assessment should respect the repository's metadata_expire setting and work offline if possible.
How can I check the age or timestamp of the cached metadata for a specific repository? How can I verify if the cache has exceeded its metadata_expire lifetime? Is there a method to refresh only that repository's metadata on demand?
To know whether DNF’s cached metadata for a newly added repo is stale, you can compare the local repomd.xml timestamp with the remote one and verify that the checksum matches. If the local file is older than the remote or its checksum differs, the cache is stale and should be refreshed. You can do this without touching other repos by targeting the specific repoid.
dnf repolist | grep <repoid>
dnf repodata --repo=<repoid> | grep repomd.xml
# Or view the file directly
stat /var/cache/dnf/<repoid>/repomd.xml
repomd.xml header to get its Last‑Modified time.
curl -I https://<repo-url>/repodata/repomd.xml | grep -i Last-Modified
If the local file’s mtime is older than the remote Last‑Modified, the cache is stale. If they match or the local file is newer, the cache is still valid.
dnf repodata --repo=<repoid> | grep -i checksum
# Compare the checksum value with the one reported by the remote repomd.xml (you can view it with
# curl -s https://<repo-url>/repodata/repomd.xml | grep checksum)
dnf clean metadata --repo=<repoid>
# or
sudo dnf clean metadata --repo=<repoid>
# Then rebuild the cache for this repo only
sudo dnf makecache --repo=<repoid>
metadata_expireThe metadata_expire option in the repo’s .repo file tells DNF how long cached metadata should be considered fresh (e.g., metadata_expire=12h). If the local file is older than that duration, DNF will automatically attempt to refresh it on the next transaction. You can inspect the current value with:
dnf config-manager --dump | grep -A1 <repoid>
All the steps above that read local files (stat, dnf repodata) work offline. Only the curl -I step requires network access to verify the remote timestamp. If you must stay offline, assume the cache is fresh if the local file is newer than the metadata_expire threshold; otherwise, plan to refresh when connectivity is available.
Do you know which DNF version you’re running (DNF 3.x or 4.x)? The cache layout and command options differ slightly between them, and the steps above assume a typical Fedora 38+ setup with DNF 4. If you’re on an older release, let me know so I can tailor the instructions accordingly.
Use comments to ask for clarification. Post a solution as an answer.
26,525 reputation · 06 Feb 2023, 00:43 UTC
After adding a new repository, the easiest way to see whether DNF thinks its metadata is still fresh is to ask DNF for the last‑update time it recorded for that repo. The command dnf repoinfo <repoid> prints a last updated field and a cached flag. If the flag is no or the timestamp is older than the repo’s metadata_expire value, the cache is stale and will be refreshed on the next transaction.
dnf repoinfo <repoid> | grep -E "cached|last updated"
For a quick offline check you can also look at the file mtime of the cached repomd.xml stored under /var/cache/dnf/<repoid>/repodata/repomd.xml and compare it with the last updated shown above.
If you want to force a refresh without touching other repos, run:
dnf repoinfo --refresh <repoid>
or rebuild only that repo’s cache with:
dnf makecache --repo=<repoid>
These commands respect the metadata_expire setting, so you don’t need to clear the entire cache.