With what you posted it would appear there are duplicates, but they are not. Look at the size of the 2 different files named rpmdb.sqlite. One is about 200 MB and the other is about 330 MB with 2 days difference.
As far as your question about which files should be the actual files and which are not, this is what I see on my F39 system
I would guess that the rpmold.XXXX files in /usr/lib/sysimage/ are leftovers from incomplete or failed upgrades and that those may be the cause of the inconsistencies that you see.
Unless rpm is actually performing a task it should remove the .rpm.lock file so that indicates a failure to complete a task and the lock file was left because it failed to complete properly. That also would explain the rpmold.XXXX directories where the old database copies are placed during upgrades and removed once the upgrade completes.
I’ve only skimmed the thread, but I don’t think anyone has mentioned this: the release version is controlled by the fedora-release package (or fedora-release-workstation, etc.). Please check rpm -qa | grep fedora-release.
If you see both 37 and 39 versions of those packages, you can try manually removing the 37 ones, and then remove the rest of the duplicate packages by following the instructions in: Upgrading Fedora Using DNF System Plugin :: Fedora Docs
This seems to happen when the upgrade is interrupted.
The new directory /usr/lib/sysimage/rpm is created with symlinks to the old rpm database files. The file /var/lib/rpm/.migratedb is created.
At the next boot, the service rpmdb-migrate.service is run to do the actual upgrade. This runs the script /usr/lib/rpm/rpmdb_migrate and the result is the symbolic links are replaced by real files and the old directory /var/lib/rpm is replaced by a symlink.
My suggestion is to move /var/lib/rpm to /var/lib/rpm.old and create the symlink like this
It would download and replace all 3500 packages. It would be the third or fourth time. I will do it hoping that at the end it will produce a correct database. BTW, I made a flash drive with fc39-live and found that there are no instructions for its use. But this is another story.
I ran $ dnf distro-sync --releasever=39. It replaced all 3500 packages, apparently from fc39 to the same fc39, but registered it properly in the database. The default release version has become 39.
NB: I have already did it a few days ago, to the same results. But after that I ran
After that, or some other manipulation I can not recall now, the default went back to 37. So, that time it did not work.
This time the /var/lib/rpm directory is a link to /usr/lib/sysimage/rpm. So, hopefully, the configuration will be stable.
The files indicating an uncompleted status .migratedb and .rpm.lock are still there:
I think it is good enough for me at this time. I will be watching for other issues since the installation happened to be not fully consistent.
Once again, thank you all for your help !
I don’t know if remove-retired-packages can be trusted. I would prefer to use dnf list extras or dnf list --extras to get a list potentially retired and then decide for each of them what to do. For example kernel modules built by akmods would be on that list.
I believe my problems started when remove-retired-package 37 command removed something needed for X, causing the desktop to die which killed the scripts. The scripts did not finish properly, leaving an inconsistent configuration. I should have run these commands from the console, not from X. Perhaps, the scripts could have been made more robust.
In general, I had become too relaxed after a few smooth installations during the last years.
Linux is normally quite robust. It tracks whether a file is in use, and the contents of files are not removed while being used. I have seen errors when many “deleted” files are still in use and a user tries to replace them with new versions.