Wir stellen fest, dass der Startvorgang von Ubuntu Desktop 22.04 besonders fragil ist und während der Konfiguration ständig hängen bleibt. Wir haben die Ursache noch nicht gefunden und dachten, wir schauen mal, ob jemand eine Ahnung hat, was los ist, während wir weiter debuggen. Vielleicht gibt es allgemeines Wissen, das es noch nicht bis in unsere Ecke des Waldes geschafft hat.
Der Startvorgang von Ubuntu 22.04 scheint besonders empfindlich auf die Ablehnung von Zeroconf-Verkehr über iptables DROP-Regeln oder das Fehlen des Avahi-Daemon-Pakets zu reagieren, insbesondere wenn physische Netzwerkverbindungen bestehen. Ubuntu 20.04 LTS weist keines dieser Verhaltensweisen auf. Das System schafft es auch nicht durch den ersten
# apt update && apt upgrade
ohne dass der Prozess hängen blieb und der nachfolgende Neustart hängen blieb. Die Ursache scheint also isoliert worden zu sein, nicht jedoch die Art des Hängenbleibens beim Booten.
Die Boot-Hänger treten auf unterschiedliche Weise auf, am häufigsten als Systemd-Sortierzyklen oder fehlgeschlagene Partitions-Mounts, die möglicherweise damit zusammenhängen. Es ist nicht klar, wo dies herrührt.
- Es könnte sich um eine Einheitenbestellung handeln, obwohl dies hier nicht offensichtlich ist.
- Möglicherweise wird die Einheitenreihenfolge durch das Fehlen von Zeroconf-Netzwerkverkehr beeinflusst (dh, indem das Erreichen von Zielen verhindert wird), aber es gibt keinen offensichtlichen Grund, warum lokale Prozesse nicht über D-Bus kommunizieren sollten, aber wenn sie über TCP-IP kommunizieren würden, warum sie keine sicherere Namensauflösung als Broadcast-Verkehr implementieren würden. Im Grunde ist überhaupt nicht klar, warum solcher Verkehr existiert, was seine Quelle oder sein Ziel ist.
- Es könnten auch nicht erfüllte Paketabhängigkeiten nach den Bereinigungen sein: Fehlermeldungen deuten vage auf Snapd hin, obwohl es sich einfach um ein anderes Opfer handeln könnte. Eine umgekehrte Abhängigkeitsanalyse könnte auf Gnome (Vanilla-Gnome-Desktop oder Gnome-Shell) (vielleicht über libapache2-mod-dnssd), Systemtap, Telepathy-Salut oder etwas anderes hindeuten, aber wie diese zusammenpassen oder was die spezifische Modalität des Hängenbleibens ist, ist mir (bestenfalls einem Laien-Systemadministrator) zumindest nicht klar.
Wir debuggen unsere üblichen Installationsskripte, die alle Arten von irrelevantem oder unnötigem Müll wie Avahi-Daemon, Network-Manager, ufw, Netplan.io, ModemManager, fprintd, ppp, Linux-PPP usw. löschen, konfigurieren das Netzwerk über systemd-networkd und ermöglichen die Ausführung von iptables beim Booten, bevor das Netzwerk aktiv ist. Der Debug-Prozess begann ohne Bereinigungen und startet dann nach paketweisen Bereinigungen neu.
Die iptables-Regeln verwerfen offensichtlich fehlerhafte Pakete, einschließlich allen Broadcast- und Zeroconf-Verkehrs. Der Kernel ist für die Paketweiterleitung konfiguriert, daher befinden sich diese DROP-Regeln in der PREROUTING-Kette der Mangle-Tabelle, sodass sie gelöscht werden, bevor sie die INPUT- und FORWARD-Ketten der Filtertabelle erreichen. Vermutlich wird dadurch auch der Verkehr zur Loopback-Schnittstelle gelöscht. INPUT-, OUTPUT- und FORWARD-Regeln AKZEPTIEREN in jedem Fall entsprechenden Verkehr vor einer Standard-DROP-Regel. Beim Debuggen wurden hier die Zeroconf-DROP-Regeln auskommentiert, wodurch der Bootvorgang in einigen Fällen, aber aus unbekannten Gründen, wiederhergestellt wird.
Interessanterweise hat keine dieser Konfigurationen Auswirkungen auf den Startvorgang, wenn die Ethernet-Kabel des Computers nicht angeschlossen sind.
Die Fehlerbehebung wird fortgesetzt, aber ich bin für konstruktive Vorschläge zu den möglichen Ursachen und zur Erzielung einer stabilen Installation besonders dankbar. Bis dies behoben ist, bin ich nicht mehr im Geschäft.