Running Fedora Linux 37 Workstation beta on two older Apple machines for a few weeks now. Just ran dnf upgrade --refresh on both machines at the same time on the same internet connection and one offers a list of Kernel (5.19.15) and Systemd (251.6-609) updates where as the other machine reports absolutely “Nothing to do”. Until running that command both machines were equal in packages and software.
It might have been updated already? You can run uname -r to see what kernel version is currently running. You can also look at the dnf history.
See a list of all DNF Transactions:
dnf history
The “Altered” column on the right tells you how many packages were modified. The “Action(s)” column tells you what was done. Using the “ID” from the left column you can get detailed info:
@Alys, Thank you for your answer, just checked, they are both at 5.19.14, one offers the update to 5.19.15, the other has “Nothing to do.”, it actually says so in the Terminal.
So DNF when connecting to the repo actually goes to a link that directs the client to the fastest mirror. It’s possible that the second machine is checking with a repo that hasn’t sync’d to the latest packages for the 37 Beta. What you can try would be removing the DNF cache rm -rf /var/cache/dnf/ then trying the upgrade again. Deleting this directory is safe and also a common practice. Then you run DNF it rebuilds the directory and cache if it’s not there.
I tried again 36 minutes later and now the 5.19.15 update is available on both machines, without having done anything to the DNF cache or similar. Would you suggest removing the fastestmirror=True option from the /etc/dnf/dnf.conf file to get them all looking at updates equally…?
The baseurl is commented out, but if you wanted them looking at a specific mirror, you would put it here. The metalink line tells DNF “Look here and it will redirect you to a mirror”, so the mirror you are using can change regularly.
Not quite. Using dnf makecache will refresh the metadata but not if your existing cache hasn’t expired. Deleting the cache directory will force it to download the latest metadata.
This is rather extreme, though as noted usually safe.
The simpler and IMHO better way would be to use dnf clean all which for all intents and purposes does the same job without manually remembering and entering the paths. It removes all previously downloaded data, including the metadata cache, so the next time dnf is run it starts from scratch. dnf clean metadata does the same but for the cache metadata only.
IMHO, this need to be clarify, giving more clarity to this:
as @computersavvy opinion delete in this way is a very intrusive performing…
Clearing the DNF Caches
It is often useful to remove entries accumulated in the /var/cache/dnf/ directory. If you remove a package from the cache, you do not affect the copy of the software installed on your system. To remove all entries for currently enabled repositories from the cache, and force to the next dnf command to refresh the metadata.
sudo dnf clean all
Note: cleaning, the hard works is doing in the next dnf command.
Other ways
This is useful if you want to make sure that the cache is fully up to date with all metadata, and regenerate the cache.
in other words, Is used to download and make usable all the metadata for the currently enabled dnf repos
sudo dnf makecache
it’s a kind of force telling dnf… hey I would like to refresh my cache now… not affecting the next dnf command.
Note: forcing, the hard works is doing here and not in the next dnf command.