I cant say for sure its the cause but I think for users waiting on upstream to work on it is a option.
Note, the commands here
sudo systemctl enable --now plocate-updatedb.timer
The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). This means they are not meant to be enabled or disabled using systemctl.
Possible reasons for having these kinds of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/, .requires/, or .upholds/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
sudo systemctl enable --now updatedb.timer
Failed to enable unit: Unit updatedb.timer does not exist
Restoring old snapshots also wont solve this one.
This is more a heads up post then anything.
Yes, that’s right: mlocate is dead. Long live plocate!
plocate is a drop-in replacement for mlocate, except the service files are named differently. That is the cause of this error:
The new service file is called plocate-updatedb.service.
I just pushed through a commit for the garuda-update script to address this:
The new version is already in the repo (garuda-update 4.8.1-1); if you run the update again you should be able to pull it down if your mirror is up to date.
The only “gotcha” is our existing /etc/updatedb.conf file is being saved as a pacsave.
The new file it is being replaced with is exactly the same, except it is missing a consideration that was added for excluding snapshots when building the database used by plocate (formerly mlocate).
People should now be notified in case of updating their system. The reason for making this a notice is that we can’t be sure plocate already installed when our migrations package is running.
I believe that information is out of date. The Btrfs-specific note referenced in that discussion has since been completely removed from the updatedb.conf man page.
Additionally, in our case we are not mounting the filesystem root. By default the root directory is a Btrfs subvolume.
I took a closer look and I think you are right: the non-root subvolmes do not seem to be getting indexed unless you enable indexing bind mounts. This seems to be contrary to the documentation:
Note that Btrfs subvolume mounts […] may get skipped if you have also mounted the filesystem root itself.
In our case, the filesystem root is not mounted (root is a subvolume), so it would seem the subvolume mounts should not be skipped.
To counteract this, make your root directory a Btrfs subvolume, too.
Again, the root directory is a Btrfs subvolume…so we are already using the suggested workaround for this issue.
And yet, as you pointed out the non-root subvolumes don’t appear to be getting indexed.
So: either the documentation isn’t accurate, or I am not understanding something about how this is supposed to work.
Either way, you are right @malkien: setting PRUNE_BIND_MOUNTS to “no” or “0” does work around this issue for anyone who wants their home subvolume (or other non-root subvolumes) indexed for using with plocate. Obviously users who have actual bind mounts in place may need to carefully consider if this is appropriate for their setup.
