YUM Metadata Cache: Why Clients Don't See New Packages
An organization uses a custom YUM repository. After adding a new RPM package to the repository, clients running 'yum update' do not see the new package. The repository metadata was regenerated using 'createrepo'. What is the most likely reason the clients are not seeing the update?
Quick Answer
The answer is that clients have cached metadata and need to run 'yum clean all' or wait for cache expiration. This is because YUM clients store a local copy of repository metadata to speed up operations, and even after you run createrepo to regenerate the metadata on the server, each client’s cached copy remains stale until it is explicitly refreshed or expires. On the LPIC-1 exam, this scenario tests your understanding of the YUM metadata lifecycle and the importance of cache management in custom repositories—a common trap is assuming that regenerating metadata on the server instantly propagates to clients. Remember that YUM prioritizes performance over freshness by default, so the client’s local cache acts as a barrier. A useful memory tip is “server creates, client caches—clean to see the changes.”
⚠ Common exam trap
It's easy for candidates to think GPG signing or version numbers are the cause, but the real issue is that YUM's metadata caching prevents clients from immediately seeing repository changes without a cache refresh.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Clients have cached metadata and need to run 'yum clean all' or wait for cache expiration
YUM clients cache repository metadata locally to improve performance. When a new package is added to a repository and 'createrepo' regenerates the metadata, clients will not see the update until they refresh their cached metadata. Running 'yum clean all' removes the cached metadata and forces a fresh download, or the cache will expire based on the 'metadata_expire' setting in the repo configuration (default is 6 hours).
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Clients have cached metadata and need to run 'yum clean all' or wait for cache expiration
Why this is correct
Cached metadata is the culprit: YUM stores repository metadata locally and only refreshes it when the expiry window lapses, so freshly regenerated repodata stays invisible until then. Running 'yum clean all' forces a metadata re-download, immediately exposing the new RPM to 'yum update'.
- ✗
The 'gpgcheck=1' option in the repo file prevents metadata download
Why it's wrong here
gpgcheck=1 verifies package signatures after download; it does not block retrieval of repomd.xml metadata, so clients would still list available packages. It is tempting because GPG failures do abort installs, and would be the cause if yum reported a signature verification error rather than missing packages.
- ✗
The repository metadata was not signed with a GPG key
Why it's wrong here
Unsigned repository metadata does not prevent yum reading it; repo_gpgcheck controls metadata signature verification, and even enabled it fails loudly rather than hiding packages. It is tempting because signing metadata is a hardening step, and would matter if the client rejected the repository with a GPG error.
- ✗
The RPM package version number is lower than the currently installed version
Why it's wrong here
A lower version number means the package is not an upgrade, so yum update correctly ignores it; the stem states a new package was added, implying a higher version. It is tempting because downgrades genuinely require yum downgrade, which would be the answer if clients needed an older release reinstalled.
Go deeper
Related to this question
About these practice questions
One of 402 original LPIC-1 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on LPIC-1
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are a Linux administrator for a company that uses a custom RPM-based distribution. The development team has built a new version of the internal tool 'monitor-app' (version 2.0) and placed the RPM package in a local YUM repository located at http://internal.repo/monitor-app-2.0.el7.x86_64.rpm. The repository metadata has been updated using 'createrepo'. On a test server running CentOS 7, you run 'yum update monitor-app' but the system reports 'No packages marked for update'. The currently installed version is 1.0. You verify that the repository is enabled and accessible via 'yum repolist'. What is the most likely cause and the correct course of action?
hard- A.Download the RPM and install it locally with 'rpm -Uvh monitor-app-2.0.el7.x86_64.rpm'
- ✓ B.Run 'yum list available | grep monitor' to see if the package is listed with a different name, then install it with the exact name
- C.Check the version number in the repository using 'yum info monitor-app' and compare with installed version
- D.Run 'yum clean all' and then 'yum update monitor-app' again
Why B: The most likely cause is that the package name in the repository differs from the installed package name (e.g., 'monitor-app' vs. 'monitor-app-2.0'). Running 'yum list available | grep monitor' will reveal the exact package name in the repository, allowing you to install it with the correct name. This is a common scenario when package naming conventions change between versions or when the repository uses a different naming scheme than the installed package.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LPIC-1 practice question is part of Courseiva's free LPI certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LPIC-1 exam.