Comment puis-je apt-get -y dist-upgrade sans une invite de configuration de Grub ?

El /etc/default/grub est généré au moment de l'installation du paquet, ce qui est nécessaire car il s'intègre à debconf. Cela signifie qu'il ne peut pas être traité comme un fichier conf de dpkg, et donc que la gestion des fichiers de configuration de dpkg ne le connaît pas.

Au lieu de cela, il utilise ucf un outil Debian plus sophistiqué pour gérer la configuration. Malheureusement, cet outil ne comprend pas les options de dpkg. Dpkg::Options::="--force-confdef" n'aidera pas. Il a cependant sa propre façon d'effectuer des mises à niveau sans avertissement, par le biais de l'application UCF_FORCE_CONFFNEW et UCF_FORCE_CONFFOLD les variables d'environnement.

ucf utilise debconf pour l'invite, donc définir l'interface debconf à noninteractive fera également taire le message. Si vous voulez vraiment des mises à jour non interactives, vous devrez faire cela de toute façon - les paquets arbitraires peuvent poser des questions à debconf (bien qu'ils ne le fassent généralement pas pendant les mises à jour).

Vous pouvez définir l'interface debconf de manière ponctuelle en ajoutant DEBIAN_FRONTEND=noninteractive à votre environnement, ou vous pouvez le définir de façon permanente en exécutant dpkg-reconfigure debconf et en sélectionnant le frontal non interactif. Si vous utilisez le frontal non interactif, vous obtiendrez la réponse par défaut à toutes les questions qu'un paquet pourrait poser.

Para ucf la réponse par défaut est "conserver le fichier existant".

Donc, la commande complète pour faire une mise à jour vraiment, 100% garantie¹ sans invitation serait .

sudo DEBIAN_FRONTEND=noninteractive apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

¹ : Il est techniquement possible pour les paquets d'utiliser une autre méthode d'invite que debconf, mais c'est contraire à la charte Debian. Si vous rencontrez un tel paquet, enregistrez un bogue.

Suite à la réponse de RAOF et après avoir passé d'innombrables heures à chercher sur le web pour pouvoir effectuer une mise à jour et une mise à niveau sans intervention manuelle sur Ubuntu 12.04, j'ai trouvé ceci grâce au fait que cet article ( https://bugs.launchpad.net/ubuntu/+source/Grub/+bug/239674/comments/1 ) signale que Grub adhère à l'UCF et non aux options de Dpkg lorsque l'on veut utiliser les mainteneurs de paquets Grub menu.lst au lieu d'éventuelles éditions locales de menu.lst.

J'ai laissé les options Dpkg force-confnew pour les autres paquets qui ne sont pas Grub.

#!/bin/bash

unset UCF_FORCE_CONFFOLD
export UCF_FORCE_CONFFNEW=YES
ucf --purge /boot/grub/menu.lst

export DEBIAN_FRONTEND=noninteractive
apt-get update
apt-get -o Dpkg::Options::="--force-confnew" --force-yes -fuy dist-upgrade

Les solutions précédentes ne fonctionnaient pas avec la version 16.04. Ceci fonctionne à partir de cette réponse sur stack overflow :

sudo DEBIAN_FRONTEND=noninteractive apt-get -y -o DPkg::options::="--force-confdef" -o DPkg::options::="--force-confold"  install grub-pc

Après de nombreux essais, la seule chose qui a fonctionné était :

dpkg-reconfigure debconf -f noninteractive -p critical
UCF_FORCE_CONFFOLD=YES apt -o Dpkg::Options::="--force-confdef" -o DPkg::Options::="--force-confold" -y dist-upgrade

Pour ce que je faisais (Ubuntu 16.04 dans Vagrant avec provisionnement), la DEBIAN_FRONTEND=noninteractive n'était pas suffisant. Grâce à d'autres dans ce fil, j'ai dû ajouter UCF_FORCE_CONFFOLD=YES para grub-pc

Je me débats avec le même problème sur Ubuntu 18.04 depuis quelques jours. Lors du lancement d'une nouvelle instance EC2 (spécifiquement ami-00035f41c82244dab), j'exécute un provisionnement automatique script (via la configuration des données utilisateur fournie au moment de l'initialisation), dont l'une des premières étapes consiste à exécuter apt update/upgrade.

Le script est bloqué pendant que l'utilisateur est interrogé sur les fichiers script modifiés - d'abord /etc/default/script, et ensuite /boot/script/menu.lst. Comme il s'exécute en mode non-surveillé lorsqu'il est fourni en tant que données utilisateur, le processus se bloque et ne se rétablit jamais.

D'après de nombreuses recherches sur Google, il semble que ce soit un problème de longue date de Grub sous une forme ou une autre, avec des corrections appliquées puis une nouvelle régression, pour autant que je puisse dire.

En fin de compte, la seule solution de contournement que j'ai pu appliquer avec succès est l'affreux hack suivant dans mon script de provisionnement. J'espère que cela permettra à quelqu'un d'autre de se sortir du pétrin !

#!/bin/bash 

apt update

### Workaround: Pre-update /etc/default/grub and remove /boot/grub/menu.lst to avoid 'file changed' prompts from blocking completion of unattended update process
patch /etc/default/grub <<'EOF'
10c10
< GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0"
---
> GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 nvme.io_timeout=4294967295"
19c19
< GRUB_TERMINAL=console
---
> #GRUB_TERMINAL=console
EOF
rm /boot/grub/menu.lst

apt upgrade -y

### Workaround part 2: re-generate /boot/grub/menu.lst
/usr/sbin/update-grub-legacy-ec2 -y

Je ne peux que supposer que le problème que j'ai rencontré est tout à fait spécifique à la version Ubuntu 18.04 AMI actuellement disponible, et toute version mise à jour qui intègre de nouveaux paquets Grub peut ne pas être soumise au même problème. En particulier, la nature des modifications apportées à /etc/default/grub ne sont pas susceptibles d'être applicables à des versions plus récentes de l'AMI. Je ne fais qu'en parler de toute façon.