Additional: Stopped the page in the browser and refreshed it. Got a message saying

Installing b2evolution... OOPS! It seems b2evolution is already installed!
Clicking on the "Your Site" tab takes me to a b2evo front page with error messages:

Requested widget container site_header does not exist for current collection #1 and skin type normal! Requested widget container navigation_hamburger does not exist for current collection #1 and skin type normal!
No sign of a username, password, or anywhere to use them.

Just logged in to the forum, so I thought, and landed on the downloads page with an error message "The requested file is not available". Wow.

The problem above: when making adjustments during installation the person installing winds up in an infinitley repetitive loop. The installer detects any databse content and reports b2evo already installed, no matter how far it has progressed, if at all beyond resetting the DB character set.

The first thing to report by way of a cure is that the table prefixes should at least be editable in the set up procedure without having to go back into the file system to do so. evo_, indeed any externally predetermined prefix, is utterly unsuitable for a multi-site setup where the DBs need to be separated. The sysadmins (I use the term loosely) need to be able to set their own, if only to remember which site they are working on after an interruption. If the only site being run on a rented VM is a single instance of b2evo or any other CMS the prefix is completely superfluous so why not allow the user to delete it?

I got around the problems by deleting everything, downloading the latest stable - allowing wget would have been useful, I never ever unpack archives on my PC - setting up a new DB with the utf8 characterset to start with, unpacking b2evo zip - what's wrong with the far more effective, flexible and safer tarball? - and using mv to change it to htdocs, copying the example.htaccess to .htaccess (with apache2 configured properly on my own server not needed but for the install script fallover in its absence), copying conf/_basic_config.template.php to conf/_basic_config.php and presetting the DB creds including prefix settings before running the install script.
A couple of chown and chmod commands and the install script ran as though perfectly oiled.

I hope that forewarns some others. Those few, simple, preliminary steps may save them an awful lot of wasted and frustrating time at least until some of these few,simple, tiresome faults are fixed.
Anybody using a Tux box (mine for this purpose is Debian Stretch on a remote rented full server with shell access but it's very similar for most distros) for the first time, just yell if any of this looks daunting or confusing. It's easy really.