VVV: Can't get a fresh install working - troubles with MariaDB

Expected Behavior

I would expect the provisioning process to complete without errors.

Current Behavior

I previously had VVV installed and wanted to start fresh for reasons. So I uninstalled Vagrant, VirtualBox and removed the former vagrant-local folder in its entirety. I restarted my Mac, reinstalled Vagrant 2.2.4 and VirtualBox 6.0.8.

When I cloned VVV, installed the vagrant-hostsupdater and provisioned the server for the first time, the whole process ultimately errored out and exited. Along the way, I did receive the following errors (not whether they’re related):

    default: grep:
    default: /etc/apt/sources.list.d/*.list
    default: : No such file or directory

    default: Setting up mariadb-server-10.3 (1:10.3.15+maria~bionic) ...
    default: 2019-06-15  0:05:32 0 [Note] /usr/sbin/mysqld (mysqld 10.3.15-MariaDB-1:10.3.15+maria~bionic) starting as process 27289 ...
    default: 2019-06-15  0:05:32 0 [Warning] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: Uses event mutexes
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: Number of pools: 1
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: Using SSE2 crc32 instructions
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: Completed initialization of buffer pool
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
    default: 2019-06-15  0:05:32 0 [Warning] InnoDB: Failed to set O_DIRECT on file./ibdata1; OPEN: Invalid argument, continuing anyway. O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662.
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: Creating shared tablespace for temporary tables
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: Waiting for purge to start
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: 10.3.15 started; log sequence number 1603959; transaction id 9
    default: 2019-06-15  0:05:32 0 [Note] Plugin 'FEEDBACK' is disabled.
    default: 2019-06-15  0:05:32 0 [Note] Recovering after a crash using tc.log
    default: 2019-06-15  0:05:32 0 [ERROR] Can't init tc log
    default:
    default: 2019-06-15  0:05:32 0 [ERROR] Aborting
    default: 2019-06-15  0:05:32 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
    default: Configuring mariadb-server-10.3
    default: -------------------------------
    default:
    default: Unable to set password for the MariaDB "root" user
    default:
    default: An error occurred while setting the password for the MariaDB administrative
    default: user. This may have happened because the account already has a password, or
    default: because of a communication problem with the MariaDB server.
    default:
    default: You should check the account's password after the package installation.
    default:
    default: Please read the /usr/share/doc/mariadb-server-10.3/README.Debian file for
    default: more information.
    default: Created symlink /etc/systemd/system/mysql.service → /lib/systemd/system/mariadb.service.
    default: Created symlink /etc/systemd/system/mysqld.service → /lib/systemd/system/mariadb.service.
    default: Created symlink /etc/systemd/system/multi-user.target.wants/mariadb.service → /lib/systemd/system/mariadb.service.
    default: Job for mariadb.service failed because the control process exited with error code.
    default: See "systemctl status mariadb.service" and "journalctl -xe" for details.
    default: invoke-rc.d: initscript mysql, action "start" failed.
    default: ● mariadb.service - MariaDB 10.3.15 database server
    default:    Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
    default:   Drop-In: /etc/systemd/system/mariadb.service.d
    default:            └─migrated-from-my.cnf-settings.conf
    default:    Active: failed (Result: exit-code) since Sat 2019-06-15 00:05:38 UTC; 10ms ago
    default:      Docs: man:mysqld(8)
    default:            https://mariadb.com/kb/en/library/systemd/
    default:   Process: 28007 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
    default:   Process: 27855 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
    default:   Process: 27844 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
    default:   Process: 27823 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
    default:  Main PID: 28007 (code=exited, status=1/FAILURE)
    default: Jun 15 00:05:38 vvv mysqld[28007]: 2019-06-15  0:05:38 0 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
    default: Jun 15 00:05:38 vvv mysqld[28007]: 2019-06-15  0:05:38 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
    default: Jun 15 00:05:38 vvv mysqld[28007]: 2019-06-15  0:05:38 6 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1017: Can't find file: './mysql/' (errno: 2 "No such file or directory")
    default: Jun 15 00:05:38 vvv mysqld[28007]: 2019-06-15  0:05:38 0 [Note] InnoDB: Buffer pool(s) load completed at 190615  0:05:38
    default: Jun 15 00:05:38 vvv mysqld[28007]: 2019-06-15  0:05:38 0 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist
    default: Jun 15 00:05:38 vvv mysqld[28007]: 2019-06-15  0:05:38 0 [Note] Server socket created on IP: '127.0.0.1'.
    default: Jun 15 00:05:38 vvv mysqld[28007]: 2019-06-15  0:05:38 0 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.user' doesn't exist
    default: Jun 15 00:05:38 vvv systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
    default: Jun 15 00:05:38 vvv systemd[1]: mariadb.service: Failed with result 'exit-code'.
    default: Jun 15 00:05:38 vvv systemd[1]: Failed to start MariaDB 10.3.15 database server.
    default: dpkg: error processing package mariadb-server-10.3 (--configure):
    default:  installed mariadb-server-10.3 package post-installation script subprocess returned error exit status 1

    default: Setting up binutils (2.30-21ubuntu1~18.04.2) ...
    default: dpkg: dependency problems prevent configuration of mariadb-server:
    default:  mariadb-server depends on mariadb-server-10.3 (>= 1:10.3.15+maria~bionic); however:
    default:   Package mariadb-server-10.3 is not configured yet.
    default:
    default: dpkg: error processing package mariadb-server (--configure):
    default:  dependency problems - leaving unconfigured
    default: Setting up python-dbus (1.2.6-1) ...
    default: No apport report written because the error message indicates its a followup error from a previous failure.

and then here’s how the provisioning process terminated:

    default: Processing triggers for ufw (0.36-0ubuntu0.18.04.1) ...
    default: Errors were encountered while processing:
    default:  mariadb-server-10.3
    default:  mariadb-server
    default: E: Sub-process /usr/bin/dpkg returned an error code (1)
    default: Installing apt-get packages returned a failure code, cleaning up apt caches then exiting
    default: Main packages check and install failed, halting provision
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

Possible Solution

Clearing this has to do with the changes to how MariaDB is packaged in v3.0, but as for what the solution is, I’m at a loss.

Steps to Reproduce

1. Remove previous instances of Vagrant, VirtualBox and VVV
2. Install everything fresh
3. Provision a new server

Full provisioning output

Context

Tried uninstalling and reinstalling VVV. I have tried on both the develop and the master branch.

Your Environment

• VVV version: v3.1.0-git::develop
• VVV Git Branch: both develop and master
• Vagrant version: 2.2.4
• VM Provider name: VirtualBox
• VM Provider version: 6.0.8
• Operating System and version: macOS Mojave 10.14.5