Bitnami/wordpress Helm Chart Fails if wp_user with id = 1 missing
By : Josh -
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.