我们发现 Ubuntu Desktop 22.04 的启动过程特别脆弱，在配置过程中始终挂起。我们还没有弄清楚具体情况，我们想看看是否有人知道我们继续调试时发生了什么。也许存在一些尚未传到我们身边的常识。
Ubuntu 22.04 的启动过程似乎对通过 iptables DROP 规则拒绝 Zeroconf 流量或缺少 avahi-daemon 包特别敏感，尤其是在存在物理网络连接的情况下。Ubuntu 20.04 LTS 没有表现出任何这种行为。该系统也无法通过其第一个
# apt update && apt upgrade
没有该进程挂起，并且随后的重新启动挂起。因此，原因似乎已被隔离，但引导挂起的形式尚未隔离。
启动挂起有多种表现，最常见的是 systemd 排序循环或分区挂载失败，这些可能相关。目前尚不清楚这在哪里出现。
- 它可能是单位排序，尽管这里没有什么明显的。
- 也许单元排序受到零配置网络流量缺失的影响（IE，通过阻止目标到达）但没有明显的原因说明为什么本地进程不会通过 d-bus 进行通信，但如果它们确实通过 tcp-ip 进行通信，为什么它们不会实现比广播流量更安全的名称解析。从根本上讲，根本不清楚为什么存在这样的流量，它的来源或目的地。
- 也可能是清除后未满足的软件包依赖关系：错误消息模糊地暗示了 snapd，尽管它可能只是另一个受害者。反向依赖关系分析可能暗示 gnome（vanilla-gnome-desktop 或 gnome-shell）（可能通过 libapache2-mod-dnssd）、systemtap、telepathy-salut 或其他东西，但它们如何组合在一起或挂起的具体形式是什么，至少对我（充其量是一个普通的系统管理员）来说并不清楚。
我们正在调试我们常用的安装脚本，这些脚本会清除各种不相关或不必要的垃圾，例如 avahi-daemon、network-manager、ufw、netplan.io、ModemManager、fprintd、ppp、linux-ppp 等，通过 systemd-networkd 配置网络，并在网络启动之前启用 iptables 在启动时运行。调试过程开始时没有清除，然后在逐个包清除后重新启动。
iptables 规则会丢弃明显是坏的数据包，包括所有广播和零配置流量。内核配置为数据包转发，因此这些 DROP 规则位于 mangle 表的 PREROUTING 链中，因此它们在到达筛选器表的 INPUT 和 FORWARD 链之前会被清除。据推测，这还会清除到环回接口的流量。在每种情况下，INPUT、OUTPUT 和 FORWARD 规则都会在默认 DROP 规则之前接受适当的流量。此处的调试涉及注释掉零配置 DROP 规则，这在某些情况下会恢复启动，但原因不明。
奇怪的是，当机器的以太网电缆拔掉时，这些配置都不会对启动过程产生任何影响。
调试仍在继续，但如果您能提供任何关于可能存在的问题以及如何实现稳定安装的建设性想法，我将不胜感激。在问题解决之前，我将停止工作。