Why Is This Not Getting Any Smoother? Plagued by brickwall issues

So, when building a Linux machine, I get a 50/50 shot that my shell commands actually get executed. I can’t see shit going on and I get no logs to review. I’m blind here.

So I’ve actually been able to manage using a ansible playbook as part of my build, but as soon as that starts working great, I run into this stupid problem. To setup Docker package management, I have to curl a gpg key and pipe it into a gpg --dearmor command. I’ve tried this with the shell provisioner, and I’m pretty sure its not running this command at all. Then when I moved it to a playbook, I use apt_key and apt_respository. I also have become set to root on an earlier task which is running fine. However, even with root it cannot dearmor the gpg key, and place the keyring.

Like should I be using packer on a Linux machine with VMWare Workstation to get some better performance, and maybe some damn insight into failures. I’m losing my damn mind!

To get some logs about whether shell command gets executed our not, below should help.

#!/bin/bash -xe

Thanks, man. I think I tried this on script file, but have since switched back to inline commands.

I just went through a full exercise of rewriting some horrible patched together packer build, so I feel your pain.

Here are my take aways from the experience:

  • Sometimes packer just doesn’t like what you’re doing … write it a different way, break it up more if you can.
  • What I found is unless your inline is only 1 or 2 lines, use external scripts – much easier to find what is wrong in your logs that way.
  • Always use set -x in your scripts
  • Almost always use set -euo pipefail … let it fail because you’ll see why it’s failing.
  • Break up the provisioners into as many groups as you can stand. I know the impulse is to do everything in one and consolidate, but this is more of a pain to maintain. Smaller, surgical scripts are the way to go.
  • At the top of each script, do a touch /tmp/starting-prov-shell-xxxx so that you can see in the resulting OS if something fails to run and you can see where it failed.
  • Run with PACKER_LOG=1 and tee the output to a file so you can review it.
  • Use a log viewer with syntax color if possible … makes things pop for review much easier.
  • Don’t be afraid to use flag files in your scripts to pass parameters/options to other provisioners further down.
  • At the end of the run, after debugging is complete, do a cleanup script that removes all of your flags, touch, etc files. Only uncomment this section when you’re 100% done.
1 Like