Ubuntu Desktop 22.04 부팅 프로세스가 특히 취약하고 구성 중에 지속적으로 중단되는 것으로 나타났습니다. 우리는 아직 양식을 결정하지 않았으며 디버깅을 계속하면서 무슨 일이 일어나고 있는지 아는 사람이 있는지 알아볼 것이라고 생각했습니다. 아마도 아직 우리 숲 속 구석구석까지 도달하지 못한 몇 가지 상식이 존재할 수도 있습니다.
Ubuntu 22.04 부팅 프로세스는 특히 물리적 네트워크 연결이 있는 경우 iptables DROP 규칙을 통한 Zeroconf 트래픽 거부 또는 avahi-daemon 패키지 부재에 민감한 것으로 보입니다. Ubuntu 20.04 LTS에서는 이러한 동작이 전혀 나타나지 않습니다. 시스템도 첫 번째 단계를 통과할 수 없습니다.
# apt update && apt upgrade
해당 프로세스가 중단되지 않고 후속 재부팅이 중단됩니다. 따라서 원인은 분리된 것으로 보이지만 부팅 정지 방식은 아닙니다.
부팅 중단은 다양하게 나타나며, 가장 일반적으로 시스템 주문 주기 또는 관련될 수 있는 파티션 마운트 실패로 나타납니다. 이것이 어디에 있는지는 확실하지 않습니다.
- 여기서는 아무것도 명확하지 않지만 단위 주문일 수 있습니다.
- 아마도 장치 순서는 zeroconf 네트워크 트래픽이 없기 때문에 영향을 받을 수 있습니다(즉, 대상에 도달하는 것을 방지하여) 로컬 프로세스가 d-bus를 통해 통신하지 않는 이유는 분명하지 않습니다. 그러나 tcp-ip를 통해 통신했다면 브로드캐스트 트래픽보다 더 안전한 이름 확인을 구현하지 않는 이유는 무엇입니까? 기본적으로 그러한 트래픽이 존재하는 이유, 소스 또는 목적지가 전혀 명확하지 않습니다.
- 또한 제거 후에 충족되지 않은 패키지 종속성이 있을 수도 있습니다. 오류 메시지는 단순히 또 다른 희생자일 수도 있지만 스냅된 것을 막연하게 암시합니다. 역의존성 분석은 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 규칙은 모든 브로드캐스트 및 zeroconf 트래픽을 포함하여 명백히 잘못된 패킷을 삭제합니다. 커널은 패킷 전달을 위해 구성되므로 이러한 DROP 규칙은 맹글 테이블의 PREROUTING 체인에 있으므로 필터 테이블의 INPUT 및 FORWARD 체인에 도달하기 전에 스크러빙됩니다. 아마도 이는 루프백 인터페이스에 대한 트래픽도 제거할 것입니다. INPUT, OUTPUT 및 FORWARD 규칙은 각 경우에 기본 DROP 규칙보다 먼저 적절한 트래픽을 허용합니다. 여기서 디버깅에는 어떤 경우에는 부팅을 복원하지만 알 수 없는 이유로 부팅을 복원하는 zeroconf DROP 규칙을 주석 처리하는 작업이 포함됩니다.
흥미롭게도 이 구성 중 어떤 것도 시스템의 이더넷 케이블이 분리되어 있을 때 부팅 프로세스에 아무런 영향을 미치지 않습니다.
디버깅은 계속되지만 작업 중인 내용과 안정적인 설치를 달성하는 방법에 대한 건설적인 생각은 특히 감사하겠습니다. 이 문제가 해결될 때까지 저는 사업을 중단합니다.