suspicious /.rpmdb root directory

There is no path with prefix "/.rpmdb/" in any @rpm5.org code as distributed.

I'd suggest deleting( or at least renaming "mv /.rpmdb /.rpmdb-FOO") to find out
whether (or what) used "/.rpmdb".

You might be able to tell whether that path is configured by typing
    rpm -v --showrc | grep rpmdb
and then pursuing what is likely a per-distro, not an RpM, choice and bug.

Note that all paths used by RPM are macros that are configurable: any path
that is _NOT_ configurable to conform with FHS or whatever other "standard"
floats your boat, is likely an omission or oversight, and should be treated like
any other bug without the need for claiming
    Non-compliant with FHS!

Output of rpm -v --showrc | grep rpmdb:
-14: _dbpath %(echo $HOME/.rpmdb)

Output of rgrep '\.rpmdb' alien* rpm* (in current sources):
rpm-4.9.1.1/debian/rpm.README.Debian: cd ~/.rpmdb
rpm-4.9.1.1/debian/patches/rpmdb-in-home.patch:+%_dbpath %(echo $HOME/.rpmdb)
rpm-4.9.1.1/debian/rpm.NEWS: each user, own database in ~/.rpmdb will be created. This avoids errors while
rpm-4.9.1.1/.pc/fix-directories.patch/macros.in:%_dbpath %(echo $HOME/.rpmdb)
rpm-4.9.1.1/macros.in:%_dbpath %(echo $HOME/.rpmdb)

I assume it's the line with $HOME/.rpmdb. Maybe sometimes an rpm command is invoked with the envvar HOME not set, if invoked over sudo, dpkg, alien (or any package using alien) or whatever. In this case "$HOME/.rpmdb" equals "/.rpmdb". Maybe we should include a test of the environment variable before using it.

E.g. cron is well known to not set $HOME by default: I'd agree that the root cause
for creating non-FHS /.rpmdb is due to $HOME not being set (and RPM patched
to use $HOME in essential/mandatory configuration like %_dbpath).

These issues are in a Debian patch to RPM and needs to be addressed within Debian/uBuntu.

If you wish rpm-4.9.1 "upstream" patched, then you need to use trac at http://rpm.org.

Status changed to 'Confirmed' because the bug affects multiple users.

I too have a ~/.rpmdb owned by root, which is why I visited this report.

These directories can indeed be safely removed.

On Ubuntu and other non-rpm-based systems, rpm is typically used to build and inspect RPM packages, not to install them or manage a database. The problem for non-rpm-based systems is that the rpm tool cannot (currently) operate on package files without accessing its database. If the rpmdb doesn't exist, you get a nasty warning (that calls itself an error) with every command:

$ rpm -qp fedora-release-18-0.8.noarch.rpm
error: cannot open Packages database in /var/lib/rpm
fedora-release-18-0.8.noarch

The fix for Debian and Ubuntu was to configure rpm such that it creates a database in $HOME/.rpmdb, since $HOME should normally be writable. See http://bugs.debian.org/551669.

If you want to prevent these directories from being created, you could try to figure out what process is running rpm with HOME set to null or /. I agree with #3, it sounds like cron.

Bottom line, I'm not sure what the bug is here. A lot of Linux commands and applications generate configuration files or directories as a side effect of running, and if you run them as root without a HOME, you'll get the same effect.

The bug is that I think it's a standard Ubuntu package which causes the creation of all /root/.rpmdb/ /.rpmdb/ and ~/.rpmdb (i just checked again I have all of them). The .rpmdb directories in the user directories are ok (but I prefer them in a /tmp/ directory if they are in fact temporary. But /.rpmdb/ in the root of the file system is just agains the LSB standard and should NEVER appear as long you only use standard ubuntu packages...

I am a strong believer in LSB as well. However this directory is not created by the rpm package. I have a standard Ubuntu install plus lsb and I do not see any of these directories. Would you be able to provide steps to reproduce from a standard install including the lsb and rpm packages?

Then again I just read your initial comment and it also sounds like you just want a support answer for why this directory exists, posted in a place where other users can find the answer as well. Is that accurate?

First I want to know what creates this directory. And I hardly believe it's one of the standard packages, so I also want to remove this issue. What I recomment in Comment 2 is a way to report an error back from rpm to the calling command or package. It could be very helpful to find the real source and it will avoid issues with new packages.

I will try to reproduce it, but I think it's a long process..

It happened again. What I did:

 - (it is a system with precise 12.04 LTS installed)
 - removed /.rpmdb/ (I did it just for fun, without any reason)
 - made sure /.rpmdb/ is not here
 - installed updates with update-manager
 - One day later, I checked /.rpmdb/ and it was there again.

ls '--time-style=+%Y-%m-%d %H:%M:%S' -l /.rpmdb/
insgesamt 4648
-rw-r--r-- 1 root root 8192 2013-03-23 14:04:04 Basenames
-rw-r--r-- 1 root root 8192 2013-03-23 14:04:04 Conflictname
-rw-r--r-- 1 root root 24576 2013-03-23 14:05:16 __db.001
-rw-r--r-- 1 root root 3850240 2013-03-23 14:05:16 __db.002
-rw-r--r-- 1 root root 83894272 2013-03-23 14:05:16 __db.003
-rw-r--r-- 1 root root 565248 2013-03-23 14:05:16 __db.004
-rw-r--r-- 1 root root 8192 2013-03-23 14:04:04 Dirnames
-rw-r--r-- 1 root root 8192 2013-03-23 14:04:04 Group
-rw-r--r-- 1 root root 8192 2013-03-23 14:04:04 Installtid
-rw-r--r-- 1 root root 8192 2013-03-23 14:04:04 Name
-rw-r--r-- 1 root root 8192 2013-03-23 14:04:04 Obsoletename
-rw-r--r-- 1 root root 12288 2013-03-23 14:04:03 Packages
-rw-r--r-- 1 root root 8192 2013-03-23 14:04:04 Providename
-rw-r--r-- 1 root root 8192 2013-03-23 14:04:04 Requirename
-rw-r--r-- 1 root root 8192 2013-03-23 14:04:04 Sha1header
-rw-r--r-- 1 root root 8192 2013-03-23 14:04:04 Sigmd5
-rw-r--r-- 1 root root 8192 2013-03-23 14:04:04 Triggername

snippet from /var/log/dpkg.log:
2013-03-23 14:03:58 configure libudev0 175-0ubuntu9.3 <none>
2013-03-23 14:03:58 status unpacked libudev0 175-0ubuntu9.3
2013-03-23 14:03:58 status half-configured libudev0 175-0ubuntu9.3
2013-03-23 14:03:58 status installed libudev0 175-0ubuntu9.3
2013-03-23 14:03:59 configure libgudev-1.0-0 1:175-0ubuntu9.3 <none>
2013-03-23 14:03:59 status unpacked libgudev-1.0-0 1:175-0ubuntu9.3
2013-03-23 14:03:59 status half-configured libgudev-1.0-0 1:175-0ubuntu9.3
2013-03-23 14:04:00 status installed libgudev-1.0-0 1:175-0ubuntu9.3
2013-03-23 14:04:00 configure linux-image-3.2.0-39-generic 3.2.0-39.62 <none>
2013-03-23 14:04:00 status unpacked linux-image-3.2.0-39-generic 3.2.0-39.62
2013-03-23 14:04:00 status half-configured linux-image-3.2.0-39-generic 3.2.0-39.62
2013-03-23 14:05:06 status installed linux-image-3.2.0-39-generic 3.2.0-39.62
2013-03-23 14:05:07 configure udev 175-0ubuntu9.3 <none>
2013-03-23 14:05:07 status unpacked udev 175-0ubuntu9.3
2013-03-23 14:05:07 status unpacked udev 175-0ubuntu9.3
2013-03-23 14:05:07 status unpacked udev 175-0ubuntu9.3
2013-03-23 14:05:08 status unpacked udev 175-0ubuntu9.3
2013-03-23 14:05:08 status unpacked udev 175-0ubuntu9.3
2013-03-23 14:05:08 status unpacked udev 175-0ubuntu9.3
2013-03-23 14:05:08 status unpacked udev 175-0ubuntu9.3
2013-03-23 14:05:09 status unpacked udev 175-0ubuntu9.3
2013-03-23 14:05:09 status half-configured udev 175-0ubuntu9.3
2013-03-23 14:05:10 status installed udev 175-0ubuntu9.3
2013-03-23 14:05:10 status triggers-pending initramfs-tools 0.99ubuntu13.1
2013-03-23 14:05:11 configure iptables 1.4.12-1ubuntu5 <none>
2013-03-23 14:05:11 status unpacked iptables 1.4.12-1ubuntu5
2013-03-23 14:05:11 status half-configured iptables 1.4.12-1ubuntu5
2013-03-23 14:05:12 status in...

The final lines of my last comment in more details:

# rm -Rf /root/.rpmdb /.rpmdb
# ls -ld /root/.rpmdb /.rpmdb
ls: Zugriff auf /root/.rpmdb nicht möglich: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf /.rpmdb nicht möglich: Datei oder Verzeichnis nicht gefunden
# /etc/kernel/postinst.d/dkms 3.8.0-14-generic /boot/vmlinuz-3.8.0-14-generic
# ls -ld /root/.rpmdb /.rpmdb
ls: Zugriff auf /.rpmdb nicht möglich: Datei oder Verzeichnis nicht gefunden
drwxr-xr-x 2 root root 4096 Mär 24 13:05 /root/.rpmdb

^^^ /root/.rpmdb appeared

# rm -Rf /root/.rpmdb /.rpmdb
# ls -ld /root/.rpmdb /.rpmdb
ls: Zugriff auf /root/.rpmdb nicht möglich: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf /.rpmdb nicht möglich: Datei oder Verzeichnis nicht gefunden
# HOME= /etc/kernel/postinst.d/dkms 3.8.0-14-generic /boot/vmlinuz-3.8.0-14-generic
# ls -ld /root/.rpmdb /.rpmdb
ls: Zugriff auf /root/.rpmdb nicht möglich: Datei oder Verzeichnis nicht gefunden
drwxr-xr-x 2 root root 4096 Mär 24 13:06 /.rpmdb

^^^ /.rpmdb appeared

#

Ok, confirmed here that dkms does call rpm if it is installed and can create an empty rpm database in / or /root as a side-effect of installing or removing kernel drivers managed with dkms.

Looks like DKMS (via kernel post-install hook, via dpkg, via apt-get) is responsible for this:

root 18414 0.0 0.0 27848 3864 pts/12 S+ 22:35 0:00 /usr/bin/perl /var/lib/dpkg/info/linux-image-3.13.0-8-generic.postinst configure 3.13.0-8.27
root 18422 0.0 0.0 4332 616 pts/12 S+ 22:35 0:00 run-parts --verbose --exit-on-error --arg=3.13.0-8-generic --arg=/boot/vmlinuz-3.13.0-8-generic /etc/kernel/postinst.d
root 18437 0.0 0.0 4428 792 pts/12 S+ 22:35 0:00 /bin/sh /usr/lib/dkms/dkms_autoinstaller start 3.13.0-8-generic
root 18440 1.0 0.0 15256 2764 pts/12 S+ 22:35 0:00 /bin/bash /usr/sbin/dkms autoinstall --kernelver 3.13.0-8-generic
root 18444 0.0 0.0 15256 1760 pts/12 S+ 22:35 0:00 /bin/bash /usr/sbin/dkms autoinstall --kernelver 3.13.0-8-generic
root 18445 0.0 0.0 14064 1192 pts/12 S+ 22:35 0:00 /bin/bash /usr/bin/rpm -qf /lib/modules/3.13.0-8-generic

The attached patch fixes DKMS to not call rpm to determine the architecture since that is quite useless.

The attachment "Disables RPM call for DKMS" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

This bug was fixed in the package rpm - 4.11.2-2.1

---------------
rpm (4.11.2-2.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Use bash to expand ~ in %_dbpath (Closes: #741324)

 -- Ben Hutchings <email address hidden> Sat, 22 Mar 2014 22:49:01 +0000

Status changed to 'Confirmed' because the bug affects multiple users.

Just found this same abovementioned /.rpmdb directory on my install. It wasn't there before and hasn't ever been there before this morning. I did not do anything involving a kernel. Although vmware player uses dkms when a new kernel is installed, no new kernel was installed today. When will 4.11.2-2.1 be made available for Trusty?

Charles, if you think the small fix for rpm is worth being applied to 14.04, the proper procedure to follow is to request an SRU, see https://wiki.ubuntu.com/StableReleaseUpdates.

I can confirm that trusty 14.04.2 LTS is affected. I have this problem on my xubuntu 14.04.2. Latest avaialable rpm package version is 4.11.1-3ubuntu0.1.

It looks like the fix in rpm in Debian is to use bash instead of dash, so the fallback from $HOME to ~ works if $HOME is not set.

I'm not sure if this particular fix is appropriate for Trusty as the rpm package doesn't currently depend on bash. Incidentally, shouldn't the fix in Debian have included the new dependency?

A "getent passwd" based solution might be better just for the SRU, since it's provided by libc-bin which is an "Essential: yes" package.

Anyway, just my thoughts. Someone will still need to prepare a suitable SRU, etc.

(the fix committed in Debian is at http://anonscm.debian.org/cgit/collab-maint/rpm.git/commit/?id=d246a0c7ed4853d1ec433fdc2ae999618f6837e2)

The bash package is an "Essential: yes" package also in Trusty so no dependency is necessary. The Debian patch should be appropriate for an SRU.

I am running Ubuntu 12.04 and also have an .rpmdb directory in my home folder and in /root as well (both directories owned by root). It looks like there hasn't been a fix for this? Although the time stamps on them are from 5-6 months ago (5 mo's ago in /root and 6 mo's ago in my home directory). At any rate, Mike, it sounds like you were saying that you can safely delete the .rpmdb directory (I'd like to at least remove the folder from my home directory). Cheers, -Don

Status changed to 'Confirmed' because the bug affects multiple users.

This also happened on Ubuntu 16.04 in 2017.