When installing on a server via cloud-init, the execution of the installation script might interfere with the automatic updates being carried out by cloud-init simultaneously leading to the following behaviour:
2026-03-28 18:57:44 [DEBUG] Checking root privileges...
2026-03-28 18:57:44 [DEBUG] Root check passed
2026-03-28 18:57:44 [DEBUG] Checking TUN device availability...
2026-03-28 18:57:44 [DEBUG] TUN device available at /dev/net/tun
2026-03-28 18:57:44 [DEBUG] Detecting operating system...
2026-03-28 18:57:44 [DEBUG] Detected OS: ubuntu (Ubuntu 20.04.5 LTS)
2026-03-28 18:57:44 [INFO] === OpenVPN Non-Interactive Install ===
2026-03-28 18:57:44 [INFO] Running in non-interactive mode with the following settings:
2026-03-28 18:57:44 [INFO] ENDPOINT=XXX
2026-03-28 18:57:44 [INFO] ENDPOINT_TYPE=4
2026-03-28 18:57:44 [INFO] CLIENT_IPV4=y
2026-03-28 18:57:44 [INFO] CLIENT_IPV6=n
2026-03-28 18:57:44 [INFO] VPN_SUBNET_IPV4=10.8.0.0
2026-03-28 18:57:44 [INFO] VPN_SUBNET_IPV6=fd42:42:42:42::
2026-03-28 18:57:44 [INFO] PORT=1194
2026-03-28 18:57:45 [INFO] PROTOCOL=udp
2026-03-28 18:57:45 [INFO] DNS=cloudflare
2026-03-28 18:57:45 [INFO] MULTI_CLIENT=n
2026-03-28 18:57:45 [INFO] AUTH_MODE=pki
2026-03-28 18:57:45 [INFO] CLIENT=client
2026-03-28 18:57:45 [INFO] CLIENT_CERT_DURATION_DAYS=3650
2026-03-28 18:57:45 [INFO] SERVER_CERT_DURATION_DAYS=3650
2026-03-28 18:57:45 === Installing OpenVPN ===
2026-03-28 18:57:45 [INFO] Setting up official OpenVPN repository...
2026-03-28 18:57:45 [CMD] apt-get update
Reading package lists...
E: Could not get lock /var/lib/apt/lists/lock. It is held by process 2566 (apt-get)
E: Unable to lock directory /var/lib/apt/lists/
2026-03-28 18:57:51 [ERROR] Update package lists failed with exit code 100
2026-03-28 18:57:51 [FATAL] Update package lists failed
2026-03-28 18:57:51 Script exited with error
Perhaps it would be a good idea to add a --retry {seconds} flag to allow the script to retry steps that might non-deterministically fail under certain installation conditions? If you generally agree with this approach, I can file a MR.
My current workaround is checking for a lock and ensuring that it's not there for at least 10 seconds before trying to start the installation.
When installing on a server via cloud-init, the execution of the installation script might interfere with the automatic updates being carried out by cloud-init simultaneously leading to the following behaviour:
Perhaps it would be a good idea to add a
--retry {seconds}flag to allow the script to retry steps that might non-deterministically fail under certain installation conditions? If you generally agree with this approach, I can file a MR.My current workaround is checking for a lock and ensuring that it's not there for at least 10 seconds before trying to start the installation.