Description of problem: It seems that every run of RPM (and DNF) now fires this warning: ~~~ $ rpm -q rpm warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. rpm-4.15.90-0.git14971.12.fc33.x86_64 ~~~ I understand that you want to change the backend, but really? Warn about it every time RPM is executed? Without providing any meaningful guidance? What is the point? Version-Release number of selected component (if applicable): $ rpm -q rpm warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. rpm-4.15.90-0.git14971.12.fc33.x86_64 How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Warning displayed all the time. Expected results: No warning at all or at least warning which provides information how to resolve the situation. Additional info:
It complains because configuration is inconsistent with what's on disk. It'll go away by doing one of the following: a) changing configuration (back to bdb) b) rpmdb --rebuilddb (which will convert to the configured format) c) reboot (which should do 2 automatically) I agree the message deserves improving, but note that "normal" users will not see such a message ever, this only happens for somebody following the daily rawhide roll.
Hmm, interesting. I have rebooted and it seems that the issue was fixed. So do I understand that I was just lucky winner in lottery and the situation was already improved? And what backend am I using now? :)
If reboot cleared it up then everything is working as intended, and you'll be on sqlite now unless you manually %_db_backend to something else. Outside rawhide, the change of default config will take place during a distro version upgrade (eg f32 -> f33) at the end of which you'll have to reboot anyhow, so its all pretty much invisible to the casual user. That's the "main use-case" of this machinery. Anyway, the idea always was to update the message to hint at possible actions, just haven't gotten around to it basically. Coming up with a message that's suitable + sufficient both upstream and Fedora isn't entirely trivial :)
Just FTR, my mock output are now full of these warnings.
Yup, known and expected consequence of the current situation. They'll go away once production koji is updated and switched to use mock bootstrap: https://pagure.io/releng/issue/9308
Well, I am not using Koji locally, just mock ;) But the truth is, that I am not using bootstrapping, because it used to be problematic. If nothing else, the bootstrap setup is more complex.
We fixed a lot of issue with bootstrap. It is so robust that since 2.x it is now by default on. Give the bootstrap one more try. It really fix a lot of issues.
Couldn't it print something like this? Run 'rpmdb --rebuilddb' to make this warning go away. Or even better just not warn at all. It's a pointless thing to say unless there's an actual problem.
Clearing NEEDINFO, answered by Mirek above.
(In reply to Richard W.M. Jones from comment #8) > Couldn't it print something like this? > > Run 'rpmdb --rebuilddb' to make this warning go away. As I've said in the earlier comments, the message might change to suggest some corrective actions, but it's subtle as --rebuilddb is not a reasonable thing to suggest in all situations either. > > Or even better just not warn at all. It's a pointless thing to say unless > there's an actual problem. Oh but there is a problem. Rpm can cope with it in some situations but not all.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
Created attachment 1726111 [details] Output from your job 66 FYI. I'm not complaining, but I just now got a warning about this "using bdb backend" in my email after upgrading my PC from Fedora 32 to Fedora 33 (screenshot attached). Googling the error message brought me straight to this bug report.
Upgrade from Fedora 30 to 33 via 32 with "dnf system-upgrade" gave me the same today.
Noticed that "rpmdb-rebuild" service fails: # journalctl -u rpmdb-rebuild -- Logs begin at Tue 2020-11-17 20:08:14 CET, end at Fri 2020-11-20 11:03:29 CET. -- Nov 20 07:08:06 fedora0.6speed.de systemd[1]: Starting RPM database rebuild... Nov 20 07:08:09 fedora0.6speed.de rpmdb[738]: error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied) Nov 20 07:08:09 fedora0.6speed.de systemd[1]: rpmdb-rebuild.service: Main process exited, code=exited, status=255/EXCEPTION Nov 20 07:08:09 fedora0.6speed.de systemd[1]: rpmdb-rebuild.service: Failed with result 'exit-code'. Nov 20 07:08:09 fedora0.6speed.de systemd[1]: Failed to start RPM database rebuild. -- Reboot -- Nov 20 10:59:20 fedora0.6speed.de systemd[1]: Starting RPM database rebuild... Nov 20 10:59:24 fedora0.6speed.de rpmdb[695]: error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied) Nov 20 10:59:24 fedora0.6speed.de systemd[1]: rpmdb-rebuild.service: Main process exited, code=exited, status=255/EXCEPTION Nov 20 10:59:24 fedora0.6speed.de systemd[1]: rpmdb-rebuild.service: Failed with result 'exit-code'. Nov 20 10:59:24 fedora0.6speed.de systemd[1]: Failed to start RPM database rebuild. # find /var/lib/rpm -ls 25165947 4 drwxr-xr-x 2 root root 4096 Nov 20 10:59 /var/lib/rpm 25297665 127168 -rw-r--r-- 1 root root 130220032 Nov 20 06:59 /var/lib/rpm/Packages 25297667 132 -rw-r--r-- 1 root root 135168 Nov 20 06:59 /var/lib/rpm/Name 25297669 15956 -rw-r--r-- 1 root root 16334848 Nov 20 06:59 /var/lib/rpm/Basenames 25297671 28 -rw-r--r-- 1 root root 28672 Nov 20 06:59 /var/lib/rpm/Group 25297675 1028 -rw-r--r-- 1 root root 1048576 Nov 20 06:59 /var/lib/rpm/Requirename 25297677 1952 -rw-r--r-- 1 root root 1998848 Nov 20 06:59 /var/lib/rpm/Providename 25297679 20 -rw-r--r-- 1 root root 20480 Nov 20 06:59 /var/lib/rpm/Conflictname 25297680 96 -rw-r--r-- 1 root root 98304 Nov 20 06:59 /var/lib/rpm/Obsoletename 25297681 16 -rw-r--r-- 1 root root 16384 Nov 20 06:58 /var/lib/rpm/Triggername 25297682 3304 -rw-r--r-- 1 root root 3379200 Nov 20 06:59 /var/lib/rpm/Dirnames 25297683 52 -rw-r--r-- 1 root root 53248 Nov 20 06:59 /var/lib/rpm/Installtid 25297686 228 -rw-r--r-- 1 root root 233472 Nov 20 06:59 /var/lib/rpm/Sigmd5 26807712 392 -rw-r--r-- 1 root root 401408 Nov 20 06:59 /var/lib/rpm/Sha1header 26807725 8 -rw-r--r-- 1 root root 8192 Nov 20 06:58 /var/lib/rpm/Filetriggername 26807812 8 -rw-r--r-- 1 root root 8192 Nov 20 06:58 /var/lib/rpm/Transfiletriggername 26808140 24 -rw-r--r-- 1 root root 24576 Nov 20 06:58 /var/lib/rpm/Recommendname 26808142 8 -rw-r--r-- 1 root root 8192 Nov 20 06:59 /var/lib/rpm/Suggestname 26808146 8 -rw-r--r-- 1 root root 8192 Nov 20 06:59 /var/lib/rpm/Supplementname 26809061 8 -rw-r--r-- 1 root root 8192 Nov 17 22:16 /var/lib/rpm/Enhancename 26808491 0 -rw-r--r-- 1 root root 0 Nov 17 22:17 /var/lib/rpm/.dbenv.lock 26808224 0 -rw-r--r-- 1 root root 0 Nov 17 23:22 /var/lib/rpm/.rpm.lock 25297637 0 -rw-r--r-- 1 root root 0 Nov 20 06:59 /var/lib/rpm/.rebuilddb
There was also a problem with abrtd service: Nov 20 10:57:10 fedora0.6speed.de abrt-server[259903]: Deleting problem directory ccpp-2020-11-20-10:56:23.191089-206594 (dup of ccpp-2020-11-20-07:08:48.898671-981) Nov 20 10:57:10 fedora0.6speed.de abrt-notification[260419]: Process 981 (rpm) crashed in db_create() Nov 20 10:57:10 fedora0.6speed.de abrtd[765]: Too many clients, refusing connections to '/var/run/abrt/abrt.socket' Nov 20 10:57:10 fedora0.6speed.de abrt-server[259968]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:10 fedora0.6speed.de abrt-server[259968]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:10 fedora0.6speed.de abrt-server[259968]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:14 fedora0.6speed.de abrtd[765]: Too many clients, refusing connections to '/var/run/abrt/abrt.socket' Nov 20 10:57:14 fedora0.6speed.de abrtd[765]: Skipping /var/spool/abrt/ccpp-2020-11-20-10:57:14.169808-207454.new: directory locked. Is a backtrace being generated? Nov 20 10:57:14 fedora0.6speed.de abrt-server[260019]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:14 fedora0.6speed.de abrt-server[260019]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:14 fedora0.6speed.de abrt-server[260019]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:38 fedora0.6speed.de abrt-server[260019]: Can't find a meaningful backtrace for hashing in '.' Nov 20 10:57:38 fedora0.6speed.de abrt-server[260019]: Preserving oops '.' because DropNotReportableOopses is 'no' Nov 20 10:57:38 fedora0.6speed.de abrtd[765]: Too many clients, refusing connections to '/var/run/abrt/abrt.socket' Nov 20 10:57:38 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:38 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:38 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:47 fedora0.6speed.de abrt-server[260065]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:48 fedora0.6speed.de abrt-server[260065]: Deleting problem directory ccpp-2020-11-20-10:56:26.763422-206732 (dup of ccpp-2020-11-20-07:08:48.898671-981) Nov 20 10:57:48 fedora0.6speed.de abrt-notification[260602]: Process 981 (rpm) crashed in db_create() Nov 20 10:57:48 fedora0.6speed.de abrtd[765]: Too many clients, refusing connections to '/var/run/abrt/abrt.socket' Nov 20 10:57:48 fedora0.6speed.de abrt-server[260093]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:48 fedora0.6speed.de abrt-server[260093]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:48 fedora0.6speed.de abrt-server[260093]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 10:57:49 fedora0.6speed.de systemd[1]: Stopping ABRT Automated Bug Reporting Tool... Nov 20 10:57:49 fedora0.6speed.de systemd[1]: abrtd.service: Succeeded. Nov 20 10:57:49 fedora0.6speed.de systemd[1]: Stopped ABRT Automated Bug Reporting Tool. Nov 20 10:57:49 fedora0.6speed.de systemd[1]: abrtd.service: Consumed 56min 28.847s CPU time. -- Reboot -- Nov 20 10:59:26 fedora0.6speed.de systemd[1]: Starting ABRT Automated Bug Reporting Tool... Nov 20 11:00:59 fedora0.6speed.de systemd[1]: abrtd.service: start operation timed out. Terminating. Nov 20 11:02:29 fedora0.6speed.de systemd[1]: abrtd.service: State 'stop-sigterm' timed out. Killing. Nov 20 11:02:29 fedora0.6speed.de systemd[1]: abrtd.service: Killing process 725 (abrtd) with signal SIGKILL. Nov 20 11:02:29 fedora0.6speed.de systemd[1]: abrtd.service: Main process exited, code=killed, status=9/KILL Nov 20 11:02:29 fedora0.6speed.de systemd[1]: abrtd.service: Failed with result 'timeout'. Nov 20 11:02:29 fedora0.6speed.de systemd[1]: Failed to start ABRT Automated Bug Reporting Tool. Nov 20 11:02:29 fedora0.6speed.de systemd[1]: abrtd.service: Consumed 1.295s CPU time.
/var/log/messages gives me more interesting stuff, whole file attached: Nov 20 11:02:33 fedora0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 20 11:02:49 fedora0 setroubleshoot[728]: failed to get list from rpm Nov 20 11:02:55 fedora0 setroubleshootd[1125]: warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. Nov 20 11:02:55 fedora0 setroubleshootd[1125]: error: cannot open Packages index using bdb - Permission denied (13) Nov 20 11:02:55 fedora0 kernel: traps: rpm[1125] trap stack segment ip:7fa6654d5e11 sp:7fffe0499580 error:0 in libdb-5.3.so[7fa6653f6000+149000] Nov 20 11:02:55 fedora0 audit[1125]: AVC avc: denied { read } for pid=1125 comm="rpm" name="Packages" dev="dm-0" ino=25297665 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0 Nov 20 11:02:55 fedora0 audit[1125]: ANOM_ABEND auid=4294967295 uid=993 gid=987 ses=4294967295 subj=system_u:system_r:setroubleshootd_t:s0 pid=1125 comm="rpm" exe="/usr/bin/rpm" sig=7 res=1 Full file uploaded to https://ylog.eu/tmp/bugreports/bugzilla.redhat.com/1836108/messages.xz
For rpmdb rebuild failures, see bug 1461313. Note that this bug is about the message itself being uninformative, not troubleshooting every possible scenario that might lead to that. However these failures do serve as an example of why it's better not to give "helpful" suggestions in the message: it really doesn't know, and bad advice is worse than none at all.
Thank you Panu, I got carried away by the logs I found while updating this. Sorry for that. https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb treats this message as "harmless" and plays down the effects of the RPM database migration. In isolation, maybe, but the problem gets attenuated by the forced migration.
(In reply to Panu Matilainen from comment #10) > (In reply to Richard W.M. Jones from comment #8) > > Couldn't it print something like this? > > > > Run 'rpmdb --rebuilddb' to make this warning go away. > > As I've said in the earlier comments, the message might change to suggest > some corrective actions, but it's subtle as --rebuilddb is not a reasonable > thing to suggest in all situations either. And it doesn't seem to help either. I've upgraded from F32 to F33 on an aarch64 board. Running dnf gives me the warning twice when it first runs, and then again N times when upgrading N packages, and then some more times just for fun. Running rpm -- rebuilddb doesn't make any difference, I still get the same warnings next time I run dnf. Rebooting doesn't make any difference either.
It seems that 'rpm --rebuilddb' fails, but silently. It doesn't print any errors, but the exit status is 255, and the journal shows selinux "denied" errors when it tries to read resolv.conf and /var/lib/rpm/.rpm.lock
[root@pine64 ~]# rpm --rebuilddb [root@pine64 ~]# echo $? 255 [root@pine64 ~]# setenforce 0 [root@pine64 ~]# rpm --rebuilddb warning: Converting database from bdb to sqlite backend [root@pine64 ~]# setenforce 1 [root@pine64 ~]# rpm --rebuilddb [root@pine64 ~]# echo $? 0 The rebuild command still gives selinux errors, but that doesn't seem to stop it succeeding now: Nov 28 19:27:10 pine64.home audit[920]: AVC avc: denied { read } for pid=920 comm="rpmdb" name="resolv.conf" dev="mmcblk0p5" ino=5838 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0 Nov 28 19:27:10 pine64.home audit[920]: AVC avc: denied { read } for pid=920 comm="rpmdb" name="resolv.conf" dev="mmcblk0p5" ino=5838 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0
The problems are not specific to aarch64, I get the same on an x86_64 machine after doing a system-upgrade from f32 to f33.
To repeat myself: For rpmdb rebuild failures, see bug 1461313. Note that this bug is about the message itself being uninformative, not troubleshooting every possible scenario that might lead to that. However these failures do serve as an example of why it's better not to give "helpful" suggestions in the message: it really doesn't know, and bad advice is worse than none at all.
Apologies, I'd missed comment 17
Panu, based on reading https://bugzilla.redhat.com/show_bug.cgi?id=1461313, and applying the workaround described there, I suspect most folks still hitting this problem are going to be in a similar situation to mine: files in their `/var/lib/rpm` directory being old enough that the SELinux context settings are just plain *wrong*, so attempting to rebuild the RPM DB always fails with SELinux errors. So based on https://bugzilla.redhat.com/show_bug.cgi?id=1461313#c92, I think the warning could pretty safely recommend "restorecon -Rv /var/lib/rpm" as a remedial step. ====== $ ls -la /var/lib/rpm | grep lock -rw-r--r--. 1 root root 0 Jul 26 2019 .dbenv.lock -rw-r--r--. 1 root root 0 Jul 28 2019 .rpm.lock $ sudo restorecon -RFv /var/lib/rpm | grep lock Relabeled /var/lib/rpm/.dbenv.lock from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 Relabeled /var/lib/rpm/.rpm.lock from unconfined_u:object_r:var_lib_t:s0 to system_u:object_r:rpm_var_lib_t:s0 ======
SELinux is merely one pretty far-fetched reason for people to see this message.
I seem to have found a solution, based upon troubleshooting the SELinux errors: $ sudo /sbin/restorecon -v /var/lib/rpm/Packages $ sudo rpmdb --rebuilddb Jonathan Wakely above noted errors like ``` Nov 28 19:27:10 pine64.home audit[920]: AVC avc: denied { read } for pid=920 comm="rpmdb" name="resolv.conf" dev="mmcblk0p5" ino=5838 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0 Nov 28 19:27:10 pine64.home audit[920]: AVC avc: denied { read } for pid=920 comm="rpmdb" name="resolv.conf" dev="mmcblk0p5" ino=5838 scontext=unconfined_u:unconfined_r:rpmdb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0 ``` The SELinux restore context command fixes the file context, so the rebuild command is now permitted. This is probably a better solution than temporarily turning off SELinux (`setenforce 0`), as it fixes an underlying problem.
Yes, restorecon on /var/lib/rpm + rpmdb --rebuilddb is the right remedy for SELinux-caused db rebuild failures, temporarily switching to permissive mode works just as well (the rebuild will also fix the rpmdb context) Incorrect SELinux labeling of rpmdb is one of many scenarios that can lead to the warning that leads people to this bug. Just as a reminder, the message does not equal a bug. /me makes a mental note to document the selinux issue in F33 common bugs...
It would also be helpful if `rpm --rebuilddb` told you when it fails. Unless you check $? or the journal, there is no indication it failed to rebuild the rpmdb.
It generally does, only the new selinux-policy denied rpmdb from outputting to the terminal... (see bug 1899548)
This issue also affects Fedora Silverblue, but the workaround of manually rebuilding is not possible since Silverblue stores the rpmdb on a read-only filesystem. See https://github.com/fedora-silverblue/issue-tracker/issues/118
(In reply to Panu Matilainen from comment #1) > I agree the message deserves improving, but note that "normal" users will > not see such a message ever, this only happens for somebody following the > daily rawhide roll. Got to this state upgrading from F31 to F33
Tried(In reply to Michal Ambroz from comment #32) > Got to this state upgrading from F31 to F33 To fix I have tried: $ sudo /sbin/restorecon -v /var/lib/rpm/Packages $ sudo rpmdb --rebuilddb But it failed: error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied) So I had to remove the lock manually and rebuild: [root]# rm /var/lib/rpm/.rpm.lock rm: remove regular empty file '/var/lib/rpm/.rpm.lock'? y [root@ash ~]# rpmdb --rebuilddb warning: Converting database from bdb to sqlite backend error: could not delete old database at /var/lib/rpmold.52986 Conversion was successful, but it failed to remove the old rpm database. Removed that one manually: rm -rf /var/lib/rpmold.52986
I had the same issue, "restorecon -v /var/lib/rpm/Packages" resolved it. I also had to delete the rpmold directory manually.
Correction to my previous comment: Warning about using bdb backend appeared after upgrading 29 --> 32 --> 33 "rpm --rebuilddb" failed with permission denied (13) and the rebuild service on boot failed as well (I disabled the service later) "restorecon -v /var/lib/rpm/Packages" and then "rpm --rebuilddb" worked.
All these permission problems are selinux-policy issues, see the linked bugs.
The message remains as-is because rpm is simply telling there's something out of ordinary that requires human attention, there's no way for rpm to tell what the right thing to do is in a particular situation. As the initial flood of F33 upgrades running into the selinux issues is probably behind us now, closing.
F33 system upgraded from F32 - I needed to do the following to remove the warning: sudo /sbin/restorecon -v /var/lib/rpm/Packages Then a sudo rpmdb --rebuilddb failed with error: can't create transaction lock on /var/lib/rpm/.rpm.lock so then did sudo setenforce 0 sudo rpmdb --rebuilddb sudo setenforce 1