![A inicialização do Ubuntu Desktop 22.04 trava sempre: dependências do Zeroconf?](https://rvso.com/image/1072170/A%20inicializa%C3%A7%C3%A3o%20do%20Ubuntu%20Desktop%2022.04%20trava%20sempre%3A%20depend%C3%AAncias%20do%20Zeroconf%3F.png)
Estamos descobrindo que o processo de inicialização do Ubuntu Desktop 22.04 é especialmente frágil, travando consistentemente durante a configuração. Ainda não identificamos a modalidade e pensamos em ver se alguém tem alguma ideia do que está acontecendo enquanto continuamos a depuração. Talvez exista algum conhecimento comum que ainda não tenha chegado ao nosso canto da floresta.
O processo de inicialização do Ubuntu 22.04 parece particularmente sensível à negação do tráfego Zeroconf por meio de regras DROP do iptables ou à ausência do pacote avahi-daemon, especialmente quando existem conexões de rede física. Ubuntu 20.04 LTS não apresenta nenhum desses comportamentos. O sistema também não consegue passar pela primeira
# apt update && apt upgrade
sem que esse processo seja interrompido e a reinicialização subsequente seja interrompida. Portanto, a causa parece ter sido isolada, mas não a modalidade de travamento da inicialização.
Os travamentos de inicialização estão presentes de várias maneiras, mais comumente como ciclos de ordenação do systemd ou falhas na montagem de partições, que podem estar relacionadas. Não está claro onde isso está localizado.
- Poderia ser uma ordem de unidade, embora nada aqui seja óbvio.
- Talvez a ordenação das unidades seja afetada pela ausência de tráfego de rede zeroconf (ou seja, impedindo que os alvos sejam alcançados), mas não existe nenhuma razão óbvia para que os processos locais não se comuniquem via d-bus, mas se eles se comunicassem via tcp-ip, por que não implementariam uma resolução de nomes mais segura do que o tráfego de broadcast. Fundamentalmente, não está claro por que esse tráfego existe, nem sua origem ou destino.
- Também podem ser dependências de pacote não atendidas após as limpezas: mensagens de erro sugerem vagamente snapd, embora possa ser simplesmente outra vítima. A análise de dependência reversa pode sugerir gnome (vanilla-gnome-desktop ou gnome-shell) (talvez via libapache2-mod-dnssd), systemtap, telepathy-salut ou qualquer outra coisa, mas como eles se encaixam ou qual é a modalidade específica do travamento , não está claro para mim (um administrador de sistema leigo, na melhor das hipóteses), pelo menos.
Estamos depurando nossos scripts de instalação habituais, que eliminam todos os tipos de lixo irrelevante ou desnecessário, como avahi-daemon, network-manager, ufw, netplan.io, ModemManager, fprintd, ppp, linux-ppp, etc., configurando a rede via systemd-networkd e habilite o iptables para ser executado na inicialização antes que a rede esteja ativa. O processo de depuração começou sem limpezas e, em seguida, reinicializou após as limpezas do pacote.
As regras do iptables descartam pacotes obviamente ruins, incluindo todo o tráfego de transmissão e zeroconf. O kernel está configurado para encaminhamento de pacotes, portanto, essas regras DROP estão na cadeia PREROUTING da tabela mangle, portanto, são limpas antes de atingir as cadeias INPUT e FORWARD da tabela de filtros. Presumivelmente, isso também elimina o tráfego para a interface de loopback. Regras INPUT, OUTPUT e FORWARD ACEITAM o tráfego apropriado antes de uma regra DROP padrão em cada caso. A depuração aqui envolveu comentar as regras DROP do zeroconf, que restaura a inicialização em alguns casos, mas por razões desconhecidas.
Curiosamente, nenhuma dessas configurações tem efeito no processo de inicialização quando a máquina está com os cabos Ethernet desconectados.
A depuração continua, mas quaisquer pensamentos construtivos sobre o que pode estar acontecendo e como conseguir uma instalação estável serão especialmente apreciados. Estou fora do mercado até que isso seja resolvido.