AppArmor 导致我的系统出现问题。我现在禁用了 AppArmor,因为它阻止我启动。我无法安装新的 apt 应用程序。当我尝试无论如何我得到...
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
当我运行该命令时,我得到...
Reloading AppArmor profiles
它就坐在那里,直到我重新启动。当我尝试删除 AppArmor 时,我收到类似的消息。这阻止我添加新应用程序和升级现有应用程序。
来自 LSB-RELEASE:
DISTRIB_ID=neon
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="KDE neon 5.27"
我可以做什么来解决这个问题?
答案1
真正禁用 AppArmor 有点棘手,但如果您知道执行这些步骤的顺序,也不是特别费力。关键实际上根本不在用户空间中,而是发生在内核命令行参数中,特别是lsm=
控制激活和优先顺序的值。Linux 安全模块。
首先通过cat /sys/kernel/security/lsm
在终端中发出命令来获取内核现在正在加载的模块的参考点,这可能会报告类似于lockdown,capability,landlock,yama,apparmor
.现在是时候让您的系统做好准备,以便在从参数中删除 AppArmor LSM 的情况下重新启动系统时不会因缺少 AppArmor 而挂起1sm=
。
查看 tp 的输出,
aa-status
看看哪些 AA 配置文件处于活动状态。Issue
sudo aa-teardown
,这应该卸载所有报告为活动的配置文件。aa-status
拆卸过程退出后,再次调用 来验证是否成功。指示您的服务管理器不要在系统启动时加载 AppArmor 守护进程,因为一旦您更改内核命令行以阻止加载模块,这必然会失败。现在大多数人似乎都在使用 SystemD,所以这看起来像......
sudo systemctl stop apparmor.service sudo systemctl disable apparmor.service
您也可以随意使用
sudo systemctl mask apparmor.service
第二个命令(我个人的偏好),这不仅会阻止它运行,还会阻止所有命令其他服务不知道它存在于系统上。或者,如果您仍然使用 rc.d,那么这个序列也能完成工作。sudo invoke-rc.d apparmor stop sudo update-rc.d -f apparmor remove
决定是立即从正在运行的系统更改引导加载程序配置,还是在启动期间中断引导过程并通过引导加载程序界面编辑当前默认内核命令行。不管怎样,这就是奇迹发生的地方。首先添加
apparmor=0
为第一个论点在内核命令行上,然后转到指定的位置,并从您在此过程开始时查看的逗号分隔列表中lsm=
删除。apparmor
如果您当前的内核参数没有lsm=
在任何地方指定(因此依赖于编译内核的默认值),请随意将其插入您喜欢的任何位置,位置不会影响这一点。需要明确的是,如果前面的命令的输出
cat
类似于lockdown,capability,landlock,yama,apparmor
,您将添加lsm=lockdown,capability,landlock,yama
到内核命令行参数以将其从安全堆栈中删除,这与将模块列入黑名单协同工作,apparmor=0
并防止低级别的内部摩擦在系统中。
现在,当您的系统启动后,您应该有lsmod | grep apparmor
和 的空输出ps aux | grep -v grep | grep apparmor
,确认它已被完全禁用。希望这将使您的包管理任务成功完成并让您重新启动并运行。
答案2
进行维护
我误读了您的评论,因此在评论变得太长之前,我将在我们一起解决问题时发布“渐进式答案”。看起来软件包安装成功,但服务拒绝加载所有配置文件。让我们从以下步骤开始:
- 现在该软件包已安装,让我们暂时使用以下命令“移开”该服务:
sudo systemctl stop apparmor
。 - 如果成功停止,请发出
sudo systemctl disable apparmor
. - 重新启动,以确保系统不会挂起。
现在该服务没有挂起系统,我们将继续...
- 阅读 AppArmor 条目乌班图维基。
- 执行更新和升级:
sudo apt update && sudo apt upgrade
- 解决上述升级中的任何问题,我们将回到 1,其中包含 Peter 的部分答案。
我相信我们要么有一个有问题的配置文件,要么有一个有问题的应用程序。如果您的更新完成,我们将看看能否找到它
准备我们的故障排除方法
因为我们不知道哪个配置文件有问题、损坏或粗鲁的,我们需要列出并测试已安装的每个 apparmor 配置文件。让我们使用一个工具来帮助我们美化输出,同时测试 APT 工具:
- 如果您还没有添加 Universe 存储库,请使用
sudo add-apt-repository universe
- 安装
tree
与sudo apt install -y tree
- 问题
tree /etc/apparmor.d/ > ~/apparmorProfilesList.txt
打开 apparmorProfilesList.txt 并计算我们需要检查的数量。
禁用配置文件
不幸的是,如果没有通过脚本编写的帮助,就无法立即禁用所有配置文件。因此,我们需要一次禁用 txt 文件中列出的每个配置文件。此外,经过更多研究后,投诉模式仅报告违反工作资料的行为。由于你的不工作,抱怨模式无济于事。所以,我们只能一一禁用,然后一一重新启用。通过评论让我知道这是否可以接受,因为需要一段时间才能写出来。
(由于没有收到任何评论,我将继续完成这个答案。)
方法
我解决这个问题的方法与下面彼得的方法有点不同,我不想“关闭”发行版支持的内核中的项目。 Ubuntu 支持 LSM 和 AppArmor,因此内核支持应保持启用状态。我的方法如下:
- 禁用 AppArmor SystemD 服务。
- 将所有 AppArmor 配置文件移动到
disabled
目录 - 重新启动 AppArmor SystemD 服务而不加载任何配置文件。请注意,这可能会生成错误,这是预期的,但它不应该挂起服务。
- 将步骤 2 中的每个配置文件一次移回活动配置文件目录,直到找到挂起 SystemD 服务的配置文件。
- 报告违规配置文件上的错误(如果有)。
实施
我们可以使用以下脚本加快禁用过程。编辑/版主请随意编辑此脚本,因为我远不是 BASH 专业人士(将此命名为“disableAllProfiles”,并使其可执行 [ +x
]):
#!/bin/bash
# NOTE : Quote it else use array to avoid problems #
PROFILES="/etc/apparmor.d/*"
for p in $PROFILES
do
echo "Processing $p file..."
# take action on each file. $p stores current profile
mv -v "$p" /etc/apparmor.d/disable/
done
ls
对 和 都/etc/apparmor.d/
发出a 问题/etc/apparmor.d/disable
。 提示:禁用应该有文件,它的父级不应该有。如果提示正确,请继续。你现在可以:
- 重新启用并重新启动 SystemD 服务:(
systemctl enable apparmor && systemctl start apparmor
由于配置文件目录为空,这可能会生成错误)。 - 将禁用目录中的第一个服务移回其父目录
/etc/apparmor.d/
。 - 重新加载服务以通知系统配置文件已添加:
sudo service apparmor reload
- 继续移动配置文件,确保每次移动后重复步骤 3,直到收到卡住
Reloading AppArmor Profiles
状态。终止该进程并记下挂起的配置文件。将挂起的配置文件放回disable
目录中,并继续沿着列表向下移动,直到所有配置文件都已放回或禁用。
错误报告
如果上述一切都完成,您最终应该得到导致禁用目录挂起的配置文件。发出如下:
dpkg -S <offending profile>
这应该告诉我们配置文件所属的包。使用Ubuntu 启动板来搜索该包。查看是否存在与您的个人资料相关的错误,或报告新错误。
笔记:如果上述测试方法在第一个配置文件或每个配置文件上都失败,则可能会发生更糟糕的情况。