Bug 1836108

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