37

I'm using Packer to create an AWS AMI based on an Ubuntu 16.04 image. In the beginning, I'm doing an upgrade:

sudo apt-get update
sudo apt-get upgrade -y

Here is the relevant part of my provisioners section:

"provisioners": [
  {
    "type": "shell",
    "inline": [
      "sudo apt-get update",
      "sudo apt-get upgrade -y"
    ]
  }
]

This breaks the automatization, however, as an interactive dialog pops up:

amazon-ebs: Found kernel: /boot/vmlinuz-4.4.0-72-generic
amazon-ebs: A new version of /boot/grub/menu.lst is available, but the version installed
amazon-ebs: currently has been locally modified.
amazon-ebs:
amazon-ebs: 1. install the package maintainer's version
amazon-ebs: 2. keep the local version currently installed
amazon-ebs: 3. show the differences between the versions
amazon-ebs: 4. show a side-by-side difference between the versions
amazon-ebs: 5. show a 3-way difference between available versions
amazon-ebs: 6. do a 3-way merge between available versions (experimental)
amazon-ebs: 7. start a new shell to examine the situation

I also tried to set export DEBIAN_FRONTEND=noninteractive before (as recommended in this answer). Unfortunately, it makes no difference.

Questions:

  • Is there a way to get past the iteractive dialog (selecting option 1 would be fine)?
  • Is it instead better to avoid upgrades and instead trust that the AMIs are up to date and contain the critical security patches?

Background: This is the relevant part of my "builders" section, where I configured it to use the latest available AMI:

"builders": [{
  "type": "amazon-ebs",
  "region": "eu-central-1",
    ...
    "source_ami_filter": {
        "filters": {
            "virtualization-type": "hvm",
            "name": "*ubuntu-xenial-16.04-amd64-server-*",
            "root-device-type": "ebs"
        },
        "owners": ["099720109477"],
        "most_recent": true
    },
  ...
}]

Note: Turns out that the noniteractive mode works if you run apt-get update with both the -y and the -q flag.

0

5 Answers 5

26

This sequence of commands works for me:

apt-get update
DEBIAN_FRONTEND=noninteractive apt-get upgrade -yq

So, DEBIAN_FRONTEND=noninteractive is correct but you also need the -q flag.

Source: https://github.com/moby/moby/issues/4032

3
  • 2
    You can (probably?) simplify that to apt-get update ; DEBIAN_FRONTEND=noninteractive apt-get upgrade -yq. I don't think apt-get update prompts for anything, so it probably doesn't need DEBIAN_FRONTEND, and thus you don't really have to export DEBIAN_FRONTEND and have it continue to exist through the rest of your environment. To whatever degree that matters to you. Commented May 17, 2017 at 23:18
  • @MichaelMol Works fine. I have updated my answer. Commented May 18, 2017 at 12:14
  • FWIW, this may lead in apt-get just skipping the package needing interaction and not upgrading it (leaving a word in the log about 'package X need manual upgrade'). If the idea is to get patched packages then it is not the way to go.
    – Tensibai
    Commented May 22, 2018 at 12:24
13

Your problem is that grub file change adhere to ucf and not debconf, as per this incident on apt list you're not alone.

As workaround I found this answer on askunbuntu. Removing the menu.lst from the UCF configuration system should be enough, for your case:

"provisioners": [
  {
    "type": "shell",
    "inline": [
      "sudo ucf --purge /boot/grub/menu.lst",
      "sudo apt-get update",
      "sudo UCF_FORCE_CONFFNEW=YES apt-get upgrade -y"
    ]
  }
]

This should avoid the grub question. Be warned that any other package using ucf will also use the maintainer package version, for a creation from a base ami this should not be a problem, but it worth being noted.

2
  • Currently, my workaround runs stable. Still, good to know there is an alternative solution. Commented May 15, 2017 at 16:38
  • I have had a similar issue with grub on Ubuntu 18.04, and I believe this ucf fix should be included in a complete solution along with the commands in the answer by @PhilippClaßen
    – RichVel
    Commented Mar 6, 2019 at 9:04
3

To add to Philipp's answer, if you are using sudo then you need to make sure to set the DEBIAN_FRONTEND variable afterwards, like so:

apt-get update
sudo DEBIAN_FRONTEND=noninteractive apt-get upgrade -yq
3
  • Or you need sudo -E, but this is still just disabling the 'hang' and just causing a skip to the package, not achieving an upgrade as expected.
    – Tensibai
    Commented May 22, 2018 at 12:22
  • How can you ensure that you upgrade the package? Commented May 23, 2018 at 10:24
  • See my answer, some packages need to be treated differently to auto answer dialogues.
    – Tensibai
    Commented May 23, 2018 at 11:53
1

I didn't notice any difference using -y or -q. Maybe because the question is about using "packer" ? (I use bare scripts)

Anyway, in my case, I got rid of the dialogs for apt upgrade using the following sed commands around it :

sed -i "s/#\ conf_force_conffold=YES/conf_force_conffold=YES/g" /etc/ucf.conf
apt-get -y upgrade
sed -i "s/conf_force_conffold=YES/#conf_force_conffold=YES/g" /etc/ucf.conf

My change is limited to the time of the upgrade.
Technically, it disables the questions about keeping or not an existing configuration when upgrading grub, but only for the time of the upgrade, to avoid side effects.

OS : Ubuntu 16.04 LTS

Hope this helps

7
  • You should link the two firsts commands with && so a failure in the first see won't allow apt-get to run if the ucf file is locked by another processus
    – Tensibai
    Commented May 16, 2017 at 19:19
  • And enforcing confold on grub is likely to leave your system unbootable , you should avoid it for grub
    – Tensibai
    Commented May 16, 2017 at 19:21
  • @Tensibai I trimmed my initial answer, but used to precise I was using this to automate new VM deployement. Of course, messing with grub is quite dangerous, and I wouldn't advise toying with this when manipulating important servers, but on the other hand... isn't apt upgrade alone extremely dangerous in such case ? Unless I have a snapshot or other efficient way of rebuilding my environment in a matter of minutes, I wouldn't try it.
    – Balmipour
    Commented May 16, 2017 at 21:05
  • 1
    apt-get upgrade is not dangerous per se. But when you enforce keeping old configurations this can be. Moreover, not checking you set the desired state OK at end (in your code a failure will leave the enforcing) that become a problem (this list will likely stop on a apt-get failure , never commenting back the line...)
    – Tensibai
    Commented May 16, 2017 at 21:10
  • 1
    It is clearly constructive. And you're especially right to point out the risk of having the uncommented line left (I hesitated using it, and will consider adding some check to prevent it). For my use case, I'm sure the risks are negligible, but someone could blindly use this without knowing the consequences. (even if one should never run random commands without understanding what they do).
    – Balmipour
    Commented May 17, 2017 at 8:37
0

You're omitting the -y parameter from your apt-get update command. If you include it, prompt should go away.

I've built an Ubuntu image with Packer as well. Here is the shell script I use to perform the update:

https://github.com/devopskatas/learningvm/blob/master/script/update.sh

This is derived from a great, well-maintained library of Ubuntu Packer builds:

https://github.com/boxcutter/ubuntu

2
  • 2
    apt-get update does only update the list of packages from the remote repository, there's no reason to set a -y there...
    – Tensibai
    Commented May 11, 2017 at 7:24
  • @Tensibai Yes, it also makes no difference. Same error. Commented May 11, 2017 at 8:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.