Add patch to /etc/updatedb.conf to include /home directory

[jorge-campo]

Problem description

New Omarchy Linux installations currently ship with the following value in in /etc/updatedb.conf:

PRUNE_BIND_MOUNTS = "yes"

With this value, the updatedb run used by locate/plocate prunes bind mounts, which results in paths under /home being omitted from the locate database. As a consequence, searches via locate/plocate do not return matches for files located in users’ home directories.

This PR updates the default configuration to:

PRUNE_BIND_MOUNTS = "no"

so that /home contents are indexed and searchable by default after installation.

Steps to reproduce the issue

1. Confirm current config: grep -n 'PRUNE_BIND_MOUNTS' /etc/updatedb.conf. Expected to show: PRUNE_BIND_MOUNTS = "yes".
2. Create a test file under /home: touch /home/$USER/locate-test-file.
3. Rebuild the locate/plocate database: sudo updatedb.
4. Search for the file: locate locate-test-file (or plocate locate-test-file). Notice the file is missing from results.

Summary of changes

During installation, before running updatedb in install/config/localdb.sh, the script now enforces PRUNE_BIND_MOUNTS = "no" in /etc/updatedb.conf (whitespace-tolerant: updates the existing setting if present, otherwise appends it), then rebuilds the locate database as usual.

Testing

1. Verified the updated localdb.sh script on an existing Omarchy 3.3.3 installation: the script executed successfully with no errors and updatedb completed as expected.

2. Built and installed a new Omarchy ISO from the omarchy-iso repository using:

   OMARCHY_INSTALLER_REPO="jorge-campo/omarchy" OMARCHY_INSTALLER_REF="fix-localdb-prune-bind-mounts" ./bin/omarchy-iso-make

   Installation completed without issues using this ISO image, and after the install, /etc/updatedb.conf contained the updated PRUNE_BIND_MOUNTS = "no" value.

Screenshot from the installation test on a virtual machine:

Note

This PR was prepared with support from GitHub Copilot.

closes #3744

[dhh]

We don't need any of this defensive guarding since this is all running against a known, fixed target on install. So you can just execute the grep/sed pair directly.

[dhh]

Good catch. We also need a migration for existing installations 👍