While I am seeing a lot of interesting changes in dnf5, I have noticed that it isn’t performing updates as expected. The only way I have been able to update packages is to first perform:
# dnf5 clean all
and then dnf5 update will work as expected.
After looking at the discussion topics for the last two months, I haven’t seen this problem mentioned, so if the problem is already known or if I am doing something wrong please let me know.
Thanks,
George Ganoe
Is this related? F41 Beta dnf: "update" updates 100+ but "distro-sync" downgrades?
In that case I re-enabled the disabled updates-testing repo (post) and seemingly dnf update works fine as-expected.
I use dnf vs dnf5, and dnf --version reports dnf5 version 5.2.6.2 (I guess dnf5 is automatically used)
I found that F41 sym-links dnf to dnf5. I just brought the Fedora 41 beta in a VM yesterday, and my repository list consists of:
Fedora 41 - x86_64
Fedora 41 openh264 (from Cisco) - x86_64
Fedora 41 - x86_64 - Updates
There are no testing repositories in the list. My main concern is that the dnf update command doesn’t do any updates unless I do a dnf clear all command first. It has never worked that way before, and it seems odd that it would be changed that way.
George Ganoe
The thing that prompted me to try an update was the the dnfdragora-updates application notified me that there were updates available, but when I ran the dnf update command no updates were done. I wondered why and thought that maybe something was wrong with the cache and after running the dnf clean all command the dnf update worked and updated the packages.
George Ganoe
I have not seen any issues applying updated with dnf on f41 kde.
What I always do is
dnf update --refresh
I think your use of dnf clean all is triggering meta data loading that I achieve with the --refresh
I suspect that you might be right about the --refresh option being similar to what I did. However, I have never had to do a --refresh in order to get the dnf update to work in the past so to make it be needed in the new dnf version seem like a regression to me.
George Ganoe
I always use --refresh because I don’t want to be using old meta data.
The default is to only update metadata after it is 48 hours old.
If you have been updating faster then 48 hours intervals that would explain why dnf clean all helped.
I believe f41 is in freeze state for testing the release candidates. This would mean that updates may also be frozen until the final release.
This also can cause some strange things to happen with dnf5 if you had any custom edits in your /etc/yum.repos.d/*repo files. When the fedora-repos package updates to go from prebeta to beta, they flipped the testing repos from enabled to disabled. If you have custom edits those file changes don’t get implemented until you run
sudo rpmconf -a
to get those files merged (either accept the Fedora packager ones with “Y” , use “D” to diff them or “N” to keep yours.
I will keep the 48 hours issue in mind for the future, but that still doesn’t explain why the dnf update didn’t work when the dnfdragora-updates application had already told me that there were updates available. I would think that the process that tells me there are updates available would have already done the meta-data update so that it shouldn’t require a --refresh option on dnf update in order to work.
George Ganoe
Could be because dnfdragora works with user-level metadata cache, whereas sudo dnf upgrade works with system cache.
There were some discussions to make dnfdragora work with system cache, but based on your experience, this didn’t happen yet apparently.
Dnf and dnfragora are two independent apps and as was noted, they use a different cache. Those cache files may easily be (and often are) out of sync.
If you wish to avoid the out of sync issue, use only one package manager so you never see the mismatch.
Thanks for the verification. I only use the dnfdragora-updates notifications because they are automatically set to be given by the default system installation. I have always used the terminal based dnf for actually doing the updates.
I am hoping that the new dnf5 will eventually get the “Last metadata expiration check: 1:55:30 ago on …” that was in the previous version as that message was a useful guide to let me know how old the metadata cache was. Currently it just says “Updating and loading repositories:” which suggests that the cache is being updated to the current time. However, my action mentioned above to clear the cache and redo the update indicates that the cache wasn’t actually updated to the current time until after it was first cleared.
George Ganoe
It is usually understood that there is always a risk of out-of-date metadata unless the dnf upgrade is run with the --refresh option. As noted, there is usually a minimum of 6 hours since the last update before dnf will automatically refresh the metadata (and it may be longer).
The --refresh option forces an immediate update without needing to perform the clean step.
The default is 48 hours in f41, I checked for my earlier reply.
Barry
I am hoping that the new dnf5 will eventually get the “Last metadata expiration check: 1:55:30 ago on …” that was in the previous version as that message was a useful guide to let me know how old the metadata cache was.
You can see that information with:
dnf5 repoinfo
For each repo’s section, look at lines containing:
Metadata expired
and
Updated
Different repositories has different expire time. For example the fedora repository has an expire time of 7 days, and fedora-updates expires in 6 hours
[fedora]
name=Fedora $releasever - $basearch
#baseurl=http://download.example/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
enabled=1
countme=1
metadata_expire=7d <<<<<<<<<<<<<<<<<<<<<<<<<
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False
This discussion has been enlightening about the operation of the dnf5 package manager especially regarding the fact that it works differently from the previous version. Since I couldn’t find any dnf5 documentation on the Fedora Docs site other than on its package page, I went to the github repository page and found a link to an online document describing the new package manager. After scanning the Welcome to DNF5’s documentation! — dnf5 documentation document pages, I realize that I will just need to get used to the new version as I do intend to eventually update my main computer OS to Fedora 41.
So, anyway, thanks to you all for your information and I think I may be able to figure out any additional pieces I will need to know from the dnf5 docs site.
George Ganoe