Bitnami/wordpress Helm Chart Fails if wp_user with id = 1 missing

If deploying the Bitnami WordPress helm chart to an existing external database, without wp-content populated, and the wp_users table does not have a user entry with id = 1, the wordpress container will never stabilize, wordpress will not install.

The wordpress directory will be created and the install will stop and the container will crash.

This was a difficult problem to troubleshoot, as the most glaring error message that I had was the following, which was not any indicator of the problem, and was not a problem:

Events: 
  Type     Reason       Age   From               Message
  ----     ------       ----  ----               -------
  Normal   Scheduled    38s   default-scheduler  Successfully assigned default/sellsayshow-wordpress-5b6967894b-w775p to ip-10-0-32-46.us-west-2.compute.internal
  Warning  FailedMount  37s   kubelet            MountVolume.SetUp failed for volume "pvc-0f39609a-909c-4a14-87bc-3d26f7afcc70" : rpc error: code = Internal desc = Could not mount "fs-a031e6
a6:/" at "/var/lib/kubelet/pods/e3c49e54-a045-4efb-aa5f-41803e011941/volumes/kubernetes.io~csi/pvc-0f39609a-909c-4a14-87bc-3d26f7afcc70/mount": mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t efs -o accesspoint=fsap-0e4ea4ff53a4c4a86,tls fs-a031e6a6:/ /var/lib/kubelet/pods/e3c49e54-a045-4efb-aa5f-41803e011941/volumes/kubernetes.io~csi/pvc-0f39609a-909c-4a14
-87bc-3d26f7afcc70/mount
Output: Could not start amazon-efs-mount-watchdog, unrecognized init system "aws-efs-csi-dri"
b'mount.nfs4: access denied by server while mounting 127.0.0.1:/'
  Normal   Pulled   6s (x3 over 36s)  kubelet  Container image "docker.io/bitnami/wordpress:5.8.1-debian-10-r6" already present on machine
  Normal   Created  6s (x3 over 36s)  kubelet  Created container wordpress
  Normal   Started  6s (x3 over 35s)  kubelet  Started container wordpress
  Warning  BackOff  2s (x3 over 26s)  kubelet  Back-off restarting failed container

The above error appeared to be a result of the Persistent Volume not being ready yet, as it was mounted properly and the wordpress directory was created on the EFS volume.

When re-deploying the bitnami/wordpress helm chart with debug = true, there was a bit more information, which led to me filing a bug report with bitnami here.