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
Yum caches repomd.xml; a fresh 'yum makecache' is needed.
- ✗
The 'gpgcheck=1' option in the repo file prevents metadata download
Why it's wrong here
gpgcheck affects package installation, not metadata download.
- ✗
The repository metadata was not signed with a GPG key
Why it's wrong here
Signing is not required for metadata refresh.
- ✗
The RPM package version number is lower than the currently installed version
Why it's wrong here
If lower, it wouldn't be offered, but the question implies it's a new package.
Go deeper
Related to this question
About these practice questions
One of 527 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.