Be aware that only the root file system is managed in a transactional way, i.e. any additional mounts added here will *not* get a seperate snapshot (so their contents cannot be rolled back) and the changes will be visible to the running system immediately (breaking the transactional concept and possibly resulting in a mix between old and new files if there are also changes to the root file system until the next reboot).

By default only /opt will be bind-mounted, as this directory is often used by third-party packages, but the applications in there are usually self-contained.

Example: To mount additional directories such as /usr/local or /var/lib/images into the update environment, add the following lines to the configuration file:

              BINDDIRS[0]="/opt"


              BINDDIRS[1]="/usr/local"


              BINDDIRS[2]="/var/lib/images"


            

If a directory contains submounts, these have to be mounted separately. For example if for some reason /usr/local should contain /usr/local/extra that is located on a different partition, both mounts will have to be listed:

              BINDDIRS[0]="/opt"


              BINDDIRS[1]="/usr/local"


              BINDDIRS[2]="/usr/local/extra"


              BINDDIRS[3]="/var/lib/images"


            

Instead of numbers it is also possible to use names for the array:

              BINDDIRS[0]="/opt"


              BINDDIRS[usrlocal]="/usr/local"


              BINDDIRS[extra]="/usr/local/extra"


              BINDDIRS[images]="/var/lib/images"


            

Note that in some situations one may be tempted to expose /var/lib directly, but this can be dangerous.

/var/lib contains a lot of data, including databases, docker images or sssd data. That data is often bound to a specific version of the software. Exposing it during an upgrade can make that an RPM post-script will make changes in place that will touch the live system, that will be directly visible to the user, breaking the guarantees that transactional-update provides.