☰

如何在没有 grub 配置提示的情况下执行 apt-get -y dist-upgrade？

tag-icon • tag-icon grub2 apt amazon-ec2
如何在没有 grub 配置提示的情况下执行 apt-get -y dist-upgrade？

每让 apt-get（或 aptitude）使用 -y 运行但不提示替换配置文件？

我做了以下事情：

ec2run ami-3c994355 --region us-east-1 -n 1 -t m1.large -z us-east-1d

在机器上：

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

我仍然会收到提示，询问我要使用哪个配置文件。这些是提示符之前的几行：

Setting up grub-pc (1.99-21ubuntu3.1) ...

然后：

                         ┌───────────────────────────────────────────────────────┤ Configuring grub-pc ├───────────────────────────────────────────────────────┐                              
                         │ A new version of configuration file /etc/default/grub is available, but the version installed currently has been locally modified.  │                              
                         │                                                                                                                                     │                              
                         │ What do you want to do about modified configuration file grub?                                                                      │                              
                         │                                                                                                                                     │                              
                         │                                     install the package maintainer's version                                                        │

答案1

该/etc/default/grub文件在软件包安装时生成，这是必需的，因为它与 debconf 集成。这意味着它不能被视为 dpkg conf 文件，因此 dpkg 的配置文件处理不知道它。

相反，它使用ucf更复杂的 Debian 工具来处理配置。不幸的是，它不理解 dpkg 选项，因此设置Dpkg::Options::="--force-confdef"无济于事。不过，它确实有自己的方式来实现无提示升级，即通过UCF_FORCE_CONFFNEW和UCF_FORCE_CONFFOLD环境变量。

ucf用于debconf提示，因此将 debconf 接口设置为noninteractive也将使消息静音。如果您确实想要非交互式更新，则无论如何都需要这样做 - 任意软件包都可能询问 debconf 问题（尽管它们通常不会在升级期间询问）。

DEBIAN_FRONTEND=noninteractive您可以通过将 debconf 界面添加到您的环境中来将其设置为一次性界面，也可以通过运行dpkg-reconfigure debconf并选择非交互式前端来永久设置它。如果您使用非交互式前端，您将获得软件包可能提出的任何问题的默认答案。

对于ucf，默认答案是“保留现有文件”。

因此，执行真正 100% 保证¹ 无提示更新的完整命令是。

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

¹：从技术上讲，软件包可以使用除 debconf 之外的其他提示方法，但这违反了 Debian 政策。如果您遇到这样的软件包，请提交错误报告。

答案2

根据 RAOF 的回答，并花了无数个小时在网上搜索如何在 Ubuntu 12.04 上执行完全无人干预的更新和 dist-upgrade 之后，我根据这篇文章想到了这个办法（https://bugs.launchpad.net/ubuntu/+source/grub/+bug/239674/comments/1) 指出，当您想要使用软件包维护者 grub menu.lst 而不是任何可能的本地 menu.lst 编辑时，grub 遵守 UCF 而不是 Dpkg 选项。

对于非 grub 的其他软件包，我保留了 Dpkg force-confnew 选项。

#!/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

答案3

以前的解决方案不适用于 16.04。这适用于这个答案在 stack overflow 上：

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

答案4

过去几天，我一直在 Ubuntu 18.04 上处理同样的问题。在启动新的 EC2 实例（特别是 ami-00035f41c82244dab）时，我运行了一个自动配置脚本（通过初始化时提供的用户数据配置），其中的第一步是运行 apt update/upgrade。

当提示用户修改 GRUB 文件时，脚本会被阻止 - 首先是 /etc/default/grub，然后是 /boot/grub/menu.lst。由于在作为用户数据提供时，此脚本以无人值守模式运行，因此进程会停滞并且永远无法恢复。

据我所知，通过大量的谷歌搜索，似乎这是一个以某种形式长期存在的 GRUB 问题，虽然已经应用了修复，但后来又出现了问题。

最终，我能够成功应用的唯一解决方法是在我的配置脚本中进行以下丑陋的破解。希望它可以帮助其他人摆脱困境！

#!/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

我只能假设我遇到的问题与当前可用的 Ubuntu 18.04 AMI 版本非常相关，并且任何包含较新 GRUB 软件包的更新版本可能不会遇到同样的问题。特别是，更改的性质/etc/default/grub不太可能适用于较新版本的 AMI。无论如何，只是把它放在那里。

相关内容