Provisioning Shell Script install-container-tools.sh failing with error: dpkg: error: dpkg frontend lock was locked by another process with pid <pid>.

[bvaughan527]

Description

When attempting to build the ubuntu-22.04-lts image the provisioning Shell Script install-container-tools.sh is failing with the below error using the main branch.

==> azure-arm.build_image: Provisioning with shell script: /agent/_work/1/s/virtual-environments/images/ubuntu/templates/../scripts/build/install-container-tools.sh
==> azure-arm.build_image: % Total % Received % Xferd Average Speed Time Time Time Current
==> azure-arm.build_image: Dload Upload Total Spent Left Speed
==> azure-arm.build_image: 100 6880k 100 6880k 0 0 26.4M 0 --:--:-- --:--:-- --:--:-- 26.5M
==> azure-arm.build_image: dpkg: error: dpkg frontend lock was locked by another process with pid 19603
==> azure-arm.build_image: Note: removing the lock file is always wrong, and can end up damaging the
==> azure-arm.build_image: locked area and the entire system. See <https://wiki.debian.org/Teams/Dpkg/FAQ>.

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 22.04
• Ubuntu 24.04
• Ubuntu Slim
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• macOS 26 Arm64
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

Image version and build link

Image version: 20251211.462

Is it regression?

No

Expected behavior

The ubuntu runner image should run the provisioner script successfully and build the image as per the runner image documenation.

Actual behavior

Runner image build fails with the below error:

==> azure-arm.build_image: Provisioning with shell script: /agent/_work/1/s/virtual-environments/images/ubuntu/templates/../scripts/build/install-container-tools.sh
==> azure-arm.build_image: % Total % Received % Xferd Average Speed Time Time Time Current
==> azure-arm.build_image: Dload Upload Total Spent Left Speed
==> azure-arm.build_image: 100 6880k 100 6880k 0 0 26.4M 0 --:--:-- --:--:-- --:--:-- 26.5M
==> azure-arm.build_image: dpkg: error: dpkg frontend lock was locked by another process with pid 19603
==> azure-arm.build_image: Note: removing the lock file is always wrong, and can end up damaging the
==> azure-arm.build_image: locked area and the entire system. See <https://wiki.debian.org/Teams/Dpkg/FAQ>.

Repro steps

1. Follow instructions at https://github.com/actions/runner-images/blob/main/docs/create-image-and-azure-resources.md to build an ubuntu-22.04-lts image.
2. Observe the the Provisioning with shell script: /agent/_work/1/s/virtual-environments/images/ubuntu/templates/../scripts/build/install-container-tools.sh step fails with the error: dpkg: error: dpkg frontend lock was locked by another process with pid .

[GitPaulo]

Hi, happy new year 🎊

I've got a few questions to help clarify this issue:

• Are you trying to manually build an image? Confused about the context, please provide more.
• install-container-tools.sh error has not yet been observed in any of our builds. dpkg: error: dpkg frontend lock was locked by another process with pid suggests dpkg is busy, if you're building it in a machine you have access to, could you please check what pid 19603 is?

Thank you, more context is appreciated.

[bvaughan527]

Hi, happy new year 🎊

I've got a few questions to help clarify this issue:

• Are you trying to manually build an image? Confused about the context, please provide more.
• install-container-tools.sh error has not yet been observed in any of our builds. dpkg: error: dpkg frontend lock was locked by another process with pid suggests dpkg is busy, if you're building it in a machine you have access to, could you please check what pid 19603 is?

Thank you, more context is appreciated.

Hi @GitPaulo, I'm building the image via an ADO pipeline. However, as of this reply, I was able to get the build to succeed on the third attempt. So it does seem that there could be a sporadic timing issue with a previous package install in the build image that is causing the dpkg -i command in the install-container-tools.sh provisioning script to throw the above error. One suggestion might be to add a sleep command before the dpkg -i command to account for any long running install.

[GitPaulo]

I do not think adding a sleep is the right approach here, as things stands:

• I have not been able to reproduce this issue
• Your issue seems transient and could be related to a lot of things as dpkg is a widely used tool. More context on your build environment would be useful

As an aside, I am aware we have this monkey patch retry:

runner-images/images/ubuntu/scripts/build/configure-apt-mock.sh

Line 10 in 84b177a

for real_tool in /usr/bin/apt /usr/bin/apt-get /usr/bin/apt-key; do

for apt and it might make sense to replace dpkg usage with apt

I'll speak with the team and explore options!

[bvaughan527]

I do not think adding a sleep is the right approach here, as things stands:

• I have not been able to reproduce this issue
• Your issue seems transient and could be related to a lot of things as dpkg is a widely used tool. More context on your build environment would be useful

As an aside, I am aware we have this monkey patch retry:

runner-images/images/ubuntu/scripts/build/configure-apt-mock.sh

Line 10 in 84b177a

for real_tool in /usr/bin/apt /usr/bin/apt-get /usr/bin/apt-key; do
for apt and it might make sense to replace dpkg usage with apt
I'll speak with the team and explore options!

Thank you very much @GitPaulo! Yes, I do agree the issue is transient. Please do let me know what you and the team decide on. You may close this issue as time permits.