Packer/Ansible: Unable to acquire dpkg lock

Today I ran into a rather odd issue attempting to patch a base image using Ansible and Packer. Randomly and sporadically, my playbook would fail with the error of:

Could not get lock /var/lib/dpkg/lock-frontend

If you ever try to run Ansible on Ubuntu 16.10 and later, be aware that Unattended Upgrades is enabled by default. On boot of new Packer bake instances, I noticed that it would sometimes lock apt to do security updates by default. I spent a good part of my day tracking this down as to why sometimes it would work and other times it would not; turns out it was a race condition (could apt finish faster then next step). Seeing as it’s 2018 and we should not be afraid of security fixes, I didn’t want to disable this because this is useful for security and such.

To get around this, I created a role called prerun, which does the following task:

# Check for unattended-upgrades
- name: Wait for automatic system updates to complete
  shell: while pgrep unattended; do sleep 10; done;

After including this in roles that used apt, my error went away. One of my builds took almost 30 seconds to get past this; which would have otherwise failed. Hope this helps another poor soul out there. 🙂



Another way as I was shown with Packer (to avoid adding additional Ansible roles) is to run a pre and post script in between your Ansible run! 

In your base Packer JSON provisioners section, you would do:

  "script": "scripts/",
  "type": "shell"
  "extra_arguments": [
  "playbook_dir": "playbooks",
  "playbook_file": "playbooks/example.yml",
  "type": "ansible-local"
  "script": "scripts/",
  "type": "shell"

In, you would need a section to do whatever you need (most likely install ansible and such):

# Ensure to disable u-u to prevent breaking later
sudo systemctl mask unattended-upgrades.service
sudo systemctl stop unattended-upgrades.service
# Ensure process is in fact off: echo "Ensuring unattended-upgrades are in fact disabled" while systemctl is-active --quiet unattended-upgrades.service; do sleep 1; done

Finally, in (and whatever else you need, like delete ansible dir and such):

sudo systemctl unmask unattended-upgrades.service
sudo systemctl start unattended-upgrades.service


Another solution could be to add this in you Ansible roles before package installation:

- name: Wait for /var/lib/dpkg/lock-frontend to be released   
shell: while lsof /var/lib/dpkg/lock-frontend ; do sleep 10; done;

Thanks Gordon Kirkland for the additional solution!

Hope one of these many solutions helps others stuck with the same problem!

DePaul Linux Community Meet-up!

We hosted our first DePaul Linux Community meetup yesterday and pictures are up! I did a live workshop with other colleagues about how to install Fedora 18, some CLI tricks, and much more! Great turnout for only the first meeting! Had a great time and hope everyone else had a great time as well!

Check us out on Google+:
Like us on FB:

This slideshow requires JavaScript.

CentOS 6.4, Virtualbox, and You!

So this weekend, I went ahead and updated my VM at home. With that being said, I ran into problems getting 6.4 to boot, installing Virtualbox Guest Additions, and other things. Fear not, I documented my steps to help all of you out! I documented as I resolved the issue, hope this helps you not pull your hair out!

1. Stuck Progress Bar on boot after installing new release

Deleting the /etc/X11/xorg.conf and letting the guest OS create a new xorg.conf usually fixes the problem.

  1. Press any key during boot sequence.
  2. Press ‘e’ to edit boot commands
  3. Look for a line that begins with kernel and press ‘e’ on that line again.
  4. Add a 3 to the end of the line, save, and boot.

You should now be in command line when you boot. Login to your account, or root then:

[root@localhost~]# rm /etc/X11/xorg.conf

For those interested, here is a list of run level summaries.

  • Runlevel 0 and 6: halt and reboot the machine, respectively.
  • Runlevel 1: No services running, only root can login.
  • Runlevel 2: Users can login but no networking.
  • Runlevel 3: Networking and text-mode.
  • Runlevel 4: unused.
  • Runlevel 5: GUI.

2. VirtualBox Guest additions upgrade: install_x11_startup_app: no script given

Here’s what we get after trying to upgrade the Guest Additions:

Installing the Window System drivers Installing X.Org Server 1.11 modules ...done.
Setting up the Window System to use the Guest Additions ...done.
You may need to restart the hal service and the Window System (or just restart the guest system) to enable the Guest Additions.
Installing graphics libraries and desktop services components!
(See the log file /var/log/vboxadd-install-x11.log for more information.)
Press Return to close this window... install_x11_startup_app: no script given

Before installing the new guest additions version, you need to remove manually 2 symlinks:

[root@localhost~]# rm /usr/lib64/VBoxGuestAdditions
[root@localhost~]# rm /usr/share/VBoxGuestAdditions

3. VirtualBox Guest Additions Upgrade: Building the OpenGL support Module FAILED

Try the following:

[myusername@localhost~] su -
[root@localhost~]# cd /media/VBOXADDITIONS_4.1.12_77245/
[root@localhost VBOXADDITIONS_4.1.12_77245]# export MAKE='/usr/bin/gmake -i'
[root@localhost VBOXADDITIONS_4.1.12_77245]# ./