Also, I was able to find out problem’s root cause. Actually, there were several causes.
My /var was mounted with “noexec” option. Avast’s virus protection signatures databases (VPS) contains not only virus signatures, but also program engines in form of shared objects (.so). Avast loads these objects in a non-standard way, trying to execute them. That won’t work with “noexec”. Since mounting the “/var” with noexec belongs to the best Linux hardening practives, as workaround one can create a sub-mount “/var/lib/avast“ mounted without “noexec”.
Feature in the vpsupdate #1. After downloading VPS to a temporary location (/var/lib/avast/Setup/tmp), Avast tries to validate the new files by starting itself with the “-d” flag, pointing to a temporary directory. But this flag does not work apparently (and is not documented in the “avast -h”), and Avast effectively tries to load VPS from its default location /var/lib/avast/defs (but there is nothing yet) and fails. Workaround: in the “do_update_vps” function, comment out the “if” block after: “# verify VPS authenticity and integrity“ (“if ! “$DAEMON” -d “$TEMP_DIR”; then … fi”)
Feature in the vpsupdate #2. While vpsupdate fails validating VPS, it clean-ups downloaded files and exits. The problem is, it forgets to clean up the file /var/lib/avast/Setup/filedir/vps9.lat, that is used as indicator of local VPS version. With this single file present and containing the latest VPS version info, vpsupdate won’t download missing VPS files. Your VPS will become inconsistent, but you know nothing about that. Workaround: manually delete /var/lib/avast/Setup/filedir/vps9.* files. Better yet, remove possible other stale files with “rm -rf /var/lib/avast/Setup/lock/ /var/lib/avast/Setup/filedir/vps9.* /var/lib/avast/Setup/tmp/ /var/lib/avast/defs“, then restart update and check that you actually have /var/lib/avast/defs/ folder with content.