27

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.

22

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

|improve this answer|||||
  • 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. – Michael Mol May 17 '17 at 23:18
  • @MichaelMol Works fine. I have updated my answer. – Philipp Claßen May 18 '17 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 May 22 '18 at 12:24
11

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.

|improve this answer|||||
  • Currently, my workaround runs stable. Still, good to know there is an alternative solution. – Philipp Claßen May 15 '17 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 Mar 6 '19 at 9:04
2

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
|improve this answer|||||
  • 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 May 22 '18 at 12:22
  • How can you ensure that you upgrade the package? – Christos Dimitroulas May 23 '18 at 10:24
  • See my answer, some packages need to be treated differently to auto answer dialogues. – Tensibai May 23 '18 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

|improve this answer|||||
  • 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 May 16 '17 at 19:19
  • And enforcing confold on grub is likely to leave your system unbootable , you should avoid it for grub – Tensibai May 16 '17 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 May 16 '17 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 May 16 '17 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 May 17 '17 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

|improve this answer|||||
  • 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 May 11 '17 at 7:24
  • @Tensibai Yes, it also makes no difference. Same error. – Philipp Claßen May 11 '17 at 8:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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