Command 'locate' doesn't work

[juanje]

The command locate is very useful to find files from the terminal, but I realized that at Silverblue it doesn't work. I tried at Fedora SIlverblue 32, but I guess the issue might be happening in other versions.

The command is installed by default at Silverblue with the packages mlocate, so it should work.

How to reproduce the issue

You can test it by running:

$ locate fstab

It won't return anything. I should return, at least, /etc/fstab, but it returns nothing.

The problem

I investigated a bit and I found the issue. At the updatedb configuration (the command that update the locate database), /etc/updatedb.conf the bind mounts are disabled:

$ cat /etc/updatedb.conf 
PRUNE_BIND_MOUNTS = "yes"
...

At the Fedora Workstation is OK to disable those type of mounts, but at Fedora Silverblue it doesn't work. But if you comment that line or change the value to no, then the updatedb and the locate commands work again.

Steps to make it work

1. Comment the line with `PRUNE_BIND_MOUNTS:

$ sudo sed -i '/PRUNE_BIND_MOUNTS/s/^/#/' /etc/updatedb.conf
$ cat /etc/updatedb.conf 
#PRUNE_BIND_MOUNTS = "yes"
...

2. Update the mlocate database:

$ sudo updatedb

3. Check for a file with the command locate:

$ locate fstab

It should give you the expected output now. Afterwards, the database will update by itself each day, the package installs a systemd unit timer that takes care of that.

Solution

I'm not sure if Fedora Silverblue has its own versions of the packages, if this could be changed after the package is already installed or how is the best way to manage this type of differences with the Workstation version.

Maybe it's not essential configuration for Fedora Workstation and can be changed upstream.

[tpopela]

Running Silverblue 33 here:

$ locate fstab
/etc/fstab

Is it still na issue on Silverblue 32?

[juanje]

I haven't updated the last version on Silverblue 32, but I've been tracking the package at Fedora and they could you do the same with a file at Fedora and they haven't change the package.
@tpopela Can you do a search for files at HOME?

[tpopela]

@juanje I can confirm that locating files in HOME doesn't work. After doing the steps that you mention in the first comment, then it does work.

Also I noticed the we should prune the /sysroot/ostree/deploy directory so we don't have the duplicates. eg:

$ locate smlouva_1
/sysroot/ostree/deploy/fedora/var/home/tpopela/Downloads/smlouva_1
/var/home/tpopela/Downloads/smlouva_1
$ vi /etc/updatedb.conf 
$ sudo updatedb
$ locate smlouva_1
/var/home/tpopela/Downloads/smlouva_1

So the change for the mlocate should look like this:

diff --git a/mlocate.spec b/mlocate.spec
index dffbb83..5d5e6e0 100644
--- a/mlocate.spec
+++ b/mlocate.spec
@@ -57,6 +57,14 @@ exit 0
 if /bin/grep -q '^[^#]*DAILY_UPDATE' %{_sysconfdir}/updatedb.conf; then
     /bin/sed -i.rpmsave -e '/DAILY_UPDATE/s/^/#/' %{_sysconfdir}/updatedb.conf
 fi
+# Bind mounts shouldn't be pruned on ostree based systems so locate works
+# properly on HOME and other directories
+if /bin/grep -i silverblue /etc/os-release &> /dev/null; then
+  if /bin/grep -q '^[^#]*PRUNE_BIND_MOUNTS' %{_sysconfdir}/updatedb.conf; then
+      /bin/sed -i.rpmsave -e '/PRUNE_BIND_MOUNTS/s/^/#/' %{_sysconfdir}/updatedb.conf
+  fi
+fi
+
 %systemd_post mlocate-updatedb.timer
 systemctl start mlocate-updatedb.timer
 
diff --git a/updatedb.conf b/updatedb.conf
index 8b0b8e1..83e8865 100644
--- a/updatedb.conf
+++ b/updatedb.conf
@@ -1,4 +1,4 @@
 PRUNE_BIND_MOUNTS = "yes"
 PRUNEFS = "9p afs anon_inodefs auto autofs bdev binfmt_misc cgroup cifs coda configfs cpuset debugfs devpts ecryptfs exofs fuse fuse.sshfs fusectl gfs gfs2 gpfs hugetlbfs inotifyfs iso9660 jffs2 lustre mqueue ncpfs nfs nfs4 nfsd pipefs proc ramfs rootfs rpc_pipefs securityfs selinuxfs sfs sockfs sysfs tmpfs ubifs udf usbfs ceph fuse.ceph"
 PRUNENAMES = ".git .hg .svn .bzr .arch-ids {arch} CVS"
-PRUNEPATHS = "/afs /media /mnt /net /sfs /tmp /udev /var/cache/ccache /var/lib/yum/yumdb /var/lib/dnf/yumdb /var/spool/cups /var/spool/squid /var/tmp /var/lib/ceph"
+PRUNEPATHS = "/afs /media /mnt /net /sfs /tmp /udev /var/cache/ccache /var/lib/yum/yumdb /var/lib/dnf/yumdb /var/spool/cups /var/spool/squid /var/tmp /var/lib/ceph /sysroot/ostree/deploy"

but I would like to have this fixed for CoreOS as well. @cgwalters @dustymabe do we have a common way to identify ostree based system inside SPEC files? As %post is run on the server, the if [ -f /run/ostree-booted ] wouldn't work.

[cgwalters]

The only interesting directories to index on ostree-based systems are /etc, /usr and /var. Allow bind mounts for those directories.

[tpopela]

Colin wrote me on IRC that the check for if [ -f /run/ostree-booted ] will work as it's being run by rpm-ostree

[jlebon]

We do populate /run/ostree-booted, but that only affects the unified core path (coreos/rpm-ostree#729). In non-unified core mode (which Silverblue is still using), it's librpm which runs the scriptlets and I don't think they'll see the stamp file in their environments. Long-term fix is to move Silverblue to unified core mode, short-term probably easier to key off of VARIANT_ID in the scriptlet.

[juanje]

This seems to be already in the RedHat's Bugzilla (for quite some time):
Bug 906591 - updatedb does not index /home when /home is a bind mount

[tpopela]

I forget to add here that I've created:

https://src.fedoraproject.org/rpms/mlocate/pull-request/3 (rawhide)
https://src.fedoraproject.org/rpms/mlocate/pull-request/4 (f33)
https://src.fedoraproject.org/rpms/mlocate/pull-request/5 (f32)

[tpopela]

This was fixed in rawhide with https://bodhi.fedoraproject.org/updates/FEDORA-2020-289e9daae3 the F33 does have a build, but no update yet and for F32, there's no build yet.

[tpopela]

This was fixed everywhere.