<p>This sequence of commands works for me:</p>

<pre><code>apt-get update
DEBIAN_FRONTEND=noninteractive apt-get upgrade -yq
</code></pre>

<p>So, <code>DEBIAN_FRONTEND=noninteractive</code> is correct but you also need the <code>-q</code> flag.</p>

<p>Source: <a href="https://github.com/moby/moby/issues/4032" rel="noreferrer">https://github.com/moby/moby/issues/4032</a></p>

CC BY-SA 3.0
2017-05-17T23:18:45.930Z
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
CC BY-SA 3.0
2017-05-18T12:14:42.207Z
@MichaelMol Works fine. I have updated my answer.
Philipp Claßen
CC BY-SA 4.0
2018-05-22T12:24:57.497Z
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
CC BY-SA 3.0
2017-05-11T08:44:43.793Z
2017-05-18T12:13:40.017Z
2017-05-18T12:13:40.017Z
Philipp Claßen
<p>To add to Philipp's answer, if you are using <code>sudo</code> then you need to make sure to set the <code>DEBIAN_FRONTEND</code> variable afterwards, like so:</p>

<pre><code>apt-get update
sudo DEBIAN_FRONTEND=noninteractive apt-get upgrade -yq
</code></pre>

CC BY-SA 4.0
2018-05-22T12:22:31.993Z
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
CC BY-SA 4.0
2018-05-23T10:24:31.827Z
How can you ensure that you upgrade the package?
Christos Dimitroulas
CC BY-SA 4.0
2018-05-23T11:53:05.263Z
See my answer, some packages need to be treated differently to auto answer dialogues.
Tensibai
CC BY-SA 4.0
2018-05-22T11:49:03.797Z
2018-05-22T11:49:03.797Z
Christos Dimitroulas
<p>Your problem is that grub file change adhere to <code>ucf</code> and not debconf, as per this <a href="https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1323772" rel="nofollow noreferrer">incident on apt list</a> you're not alone.</p>

<p>As workaround I found <a href="https://askubuntu.com/a/262445/398662">this answer</a> on askunbuntu. Removing the <code>menu.lst</code> from the UCF configuration system should be enough, for your case:</p>

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

<p>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.</p>

CC BY-SA 3.0
2017-05-15T16:38:59.833Z
Currently, my workaround runs stable. Still, good to know there is an alternative solution.
Philipp Claßen
CC BY-SA 4.0
2019-03-06T09:04:37.903Z
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
CC BY-SA 4.0
2017-05-11T09:27:49.267Z
2020-02-05T15:35:03.587Z
2020-02-05T15:35:03.587Z
Tensibai
<p>I didn't notice any difference using -y or -q. Maybe because the question is about using "packer" ?  (I use bare scripts)</p>

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

<pre><code>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
</code></pre>

<p>My change is limited to the time of the upgrade.
<br>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.</p>

<p>OS : Ubuntu 16.04 LTS</p>

<p><em>Hope this helps</em></p>

CC BY-SA 3.0
2017-05-16T19:19:54.120Z
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
CC BY-SA 3.0
2017-05-16T19:21:55.577Z
And enforcing confold on grub is likely to leave your system unbootable , you should avoid it for grub
Tensibai
CC BY-SA 3.0
2017-05-16T21:05:30.377Z
@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
CC BY-SA 3.0
2017-05-16T21:10:23.153Z
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
CC BY-SA 3.0
2017-05-17T07:58:00.053Z
(Just in case: that's intended to be a constructive criticism, the answer is absolutely valid, even if I do prefer the envrironment variable method :))
Tensibai
CC BY-SA 3.0
2017-05-17T08:37:22.027Z
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
CC BY-SA 3.0
2017-05-17T08:44:22.190Z
And about *"enforcing confold on grub is likely to leave your system unbootable"*, thats what I was afraid of too.  Since I use AWS VMs, I juste don't want to even know grub exists (and have no idea if it has been customized or not).  I just removed the needed interaction to select the default given proposition, but it might be better to accept the file's replacement.
In my case, if the newly created VM became unbootable, I'll notice it immediatly, shut it down, and provision a new one instead.

I don't think automating any update is a good idea outside of initial deployment, anyway.
Balmipour
CC BY-SA 3.0
2017-05-16T15:34:40.867Z
2017-05-16T15:34:40.867Z
Balmipour
<p>You're omitting the <code>-y</code> parameter from your <code>apt-get update</code> command.  If you include it, prompt should go away.</p>

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

<p><a href="https://github.com/devopskatas/learningvm/blob/master/script/update.sh" rel="nofollow noreferrer">https://github.com/devopskatas/learningvm/blob/master/script/update.sh</a></p>

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

<p><a href="https://github.com/boxcutter/ubuntu" rel="nofollow noreferrer">https://github.com/boxcutter/ubuntu</a></p>

CC BY-SA 3.0
2017-05-11T07:24:09.330Z
`apt-get update ` does only update the list of packages from the remote repository, there's no reason to set a -y there...
Tensibai
CC BY-SA 3.0
2017-05-11T08:42:24.417Z
@Tensibai Yes, it also makes no difference. Same error.
Philipp Claßen
CC BY-SA 3.0
2017-05-10T17:54:17.463Z
2017-05-10T17:54:17.463Z
Dave Swersky
<p>I'm using <a href="https://www.packer.io/" rel="noreferrer">Packer</a> to create an AWS AMI based on an Ubuntu 16.04 image. In the beginning, I'm doing an upgrade:</p>

<pre><code>sudo apt-get update
sudo apt-get upgrade -y
</code></pre>

<p>Here is the relevant part of my provisioners section:</p>

<pre><code>"provisioners": [
  {
    "type": "shell",
    "inline": [
      "sudo apt-get update",
      "sudo apt-get upgrade -y"
    ]
  }
]
</code></pre>

<p>This breaks the automatization, however, as an interactive dialog pops up:</p>

<pre><code>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
</code></pre>

<p>I also tried to set <code>export DEBIAN_FRONTEND=noninteractive</code> before (as recommended in <a href="https://askubuntu.com/a/190332/117753">this answer</a>). Unfortunately, it makes no difference.</p>

<p><strong>Questions:</strong></p>

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

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

<pre><code>"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
    },
  ...
}]
</code></pre>

<p><strong>Note</strong>: Turns out that the <code>noniteractive</code> mode works if you run apt-get update with both the <code>-y</code> and the <code>-q</code> flag.</p>

<amazon-web-services><amazon-ami><packer>
How to avoid interactive dialogs when running "apt-get upgrade -y" in Ubuntu 16.04 when packaging with Packer?
Philipp Claßen
# How to avoid interactive dialogs when running "apt-get upgrade -y" in Ubuntu 16.04 when packaging with Packer?

(Asked by: username_0 on 2017-05-10)

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.

**Tags:** amazon-web-services, amazon-ami, packer


---

## 5 answers

### Answer by username_0 on 2017-05-11. Score: 26 | Accepted answer

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

> **Comments:**
> **username_1**: 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.  
> **username_0**: @MichaelMol Works fine. I have updated my answer.  
> **username_2**: 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.  

---

### Answer by username_2 on 2017-05-11. Score: 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.

> **Comments:**
> **username_0**: Currently, my workaround runs stable. Still, good to know there is an alternative solution.  
> **username_4**: 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  

---

### Answer by username_3 on 2018-05-22. Score: 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

> **Comments:**
> **username_2**: 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.  
> **username_3**: How can you ensure that you upgrade the package?  
> **username_2**: See my answer, some packages need to be treated differently to auto answer dialogues.  

---

### Answer by username_5 on 2017-05-16. Score: 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

> **Comments:**
> **username_2**: 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  
> **username_2**: And enforcing confold on grub is likely to leave your system unbootable , you should avoid it for grub  
> **username_5**: @username_2 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.  
> **username_2**: 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...)  
> **username_2**: (Just in case: that's intended to be a constructive criticism, the answer is absolutely valid, even if I do prefer the envrironment variable method :))  
> **username_5**: 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).  
> **username_5**: And about *"enforcing confold on grub is likely to leave your system unbootable"*, thats what I was afraid of too.  Since I use AWS VMs, I juste don't want to even know grub exists (and have no idea if it has been customized or not).  I just removed the needed interaction to select the default given proposition, but it might be better to accept the file's replacement. In my case, if the newly created VM became unbootable, I'll notice it immediatly, shut it down, and provision a new one instead.  I don't think automating any update is a good idea outside of initial deployment, anyway.  

---

### Answer by username_6 on 2017-05-10. Score: 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>

> **Comments:**
> **username_2**: `apt-get update ` does only update the list of packages from the remote repository, there's no reason to set a -y there...  
> **username_0**: @username_2 Yes, it also makes no difference. Same error.  

---

