我們發現 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 規則之前接受適當的流量。這裡的調試涉及註解掉 Zeroconf DROP 規則，這會在某些情況下恢復啟動，但原因未知。
奇怪的是，當機器拔掉乙太網路電纜時，這些配置都不會影響啟動過程。
調試仍在繼續，但任何關於可能起作用的內容以及如何實現穩定安裝的建設性想法將特別受到讚賞。在這個問題解決之前我就失業了。