Search Results for: yum

Introduction We’ve explored the yum package manager for RHEL based systems extensively in previous yum. In this article, we will present the cause and fix for the message “Repodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fast” which you might occassionally come across while running yum commands.   Cause of the message YUM maintains a cache of repository related information in the /var/cache/yum/$basearch/$releasever/ directory, where $basearch and $releasever are Yum variables referring to base architecture of the system and the release version of Red Hat Enterprise Linux.  Along with some metadata yum also stores downloaded packages temporarily in this location while the packages are being installed. Once the packages are installed successfully they are removed from the cache directories. If you are working on a server that has not been able to connect to an active yum repository server for several weeks then you will see this message when you run a yum command indicating the presence of outdated repository entries in the yum cache.This basically means that the yum cache directory is not up to date. [root@linuxnix ~]# yum install zip Loaded plugins: fastestmirror, langpacks Repodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fast The old repodata warning also gets triggered if you restore from an old server snapshots for those using VPS servers or cloud servers.  It is merely...

Introduction The yum package manager maintains a history of all yum based transactions i.e. software installation, update and removal operations. This history is kept in an sqlite database (rpmdb) which is available in the /var/lib/yum/history/ directory. The transaction history in the rpmdb can be queried via the yum history command. We would also like to point out that a log of package installs, updates and removals is maintained in a text file as well located at /var/log/yum.log. The file provides one line descriptions about the yum related actions that were performed. But a very interesting facet of the yum transaction history is that transactions can be repeated and reversed and also incomplete transactions can actually be resumed. In this article we’ll be focusing on how we could resume incomplete yum transactions and complete them to fruition.   Demonstration With a basic understanding of how yum transactions are maintained, let’s perform a practical demonstration of how we could resume an incomplete yum transaction. Consider the following operation, we are just installing the openssl package on our system. What if during the installation we loose our network connectivity. This is just a single package so repeating the installation isn’t challenging but if it were an entire system update then redoing the entire task from scratch would be tedious. To simulate an interruption I hit the ctrl+c key to stop the yum...