Descubrimos que el proceso de arranque de Ubuntu Desktop 22.04 es especialmente frágil y se bloquea constantemente durante la configuración. Todavía no hemos identificado la modalidad y pensamos en ver si alguien tiene alguna idea de lo que está pasando mientras continuamos depurando. Quizás exista algún conocimiento común que aún no haya llegado a nuestro rincón del bosque.
El proceso de arranque de Ubuntu 22.04 parece particularmente sensible a la denegación del tráfico Zeroconf a través de las reglas DROP de iptables o la ausencia del paquete avahi-daemon, especialmente cuando existen conexiones de red físicas. Ubuntu 20.04 LTS no muestra nada de este comportamiento. El sistema tampoco puede superar su primera
# apt update && apt upgrade
sin que ese proceso se cuelgue, y el posterior reinicio se cuelgue. Entonces, la causa parece haber sido aislada pero no la modalidad del bloqueo del arranque.
El arranque se bloquea de diversas formas, más comúnmente como ciclos de ordenamiento del sistema o montajes fallidos de particiones, que pueden estar relacionados. No está claro dónde se remonta esto.
- Podría ser un pedido de unidades, aunque aquí nada es obvio.
- Quizás el orden de las unidades se vea afectado por la ausencia de tráfico de red zeroconf (es decir, al evitar que se alcancen los objetivos) pero no existe ninguna razón obvia por la cual los procesos locales no se comunicarían a través de d-bus, pero si se comunicaran a través de tcp-ip por qué no implementarían una resolución de nombres más segura que el tráfico de transmisión. Fundamentalmente, no está del todo claro por qué existe dicho tráfico, su origen o destino.
- También podrían ser dependencias de paquetes no satisfechas después de las purgas: los mensajes de error sugieren vagamente a snapd, aunque puede ser simplemente otra víctima. El análisis de dependencia inversa puede sugerir gnome (vanilla-gnome-desktop o gnome-shell) (quizás a través de libapache2-mod-dnssd), systemtap, telepathy-salut o algo más, pero cómo encajan entre sí o cuál es la modalidad específica del bloqueo. , no está claro, al menos para mí (un administrador de sistemas no profesional, en el mejor de los casos).
Estamos depurando nuestros scripts de instalación habituales, que eliminan todo tipo de basura irrelevante o innecesaria, como avahi-daemon, network-manager, ufw, netplan.io, ModemManager, fprintd, ppp, linux-ppp, etc., configuramos la red a través de systemd-networkd y habilite iptables para que se ejecute en el arranque antes de que la red esté activa. El proceso de depuración comenzó sin purgas y luego se reinicia después de las purgas de paquetes.
Las reglas de iptables descartan paquetes obviamente malos, incluido todo el tráfico de transmisión y zeroconf. El kernel está configurado para el reenvío de paquetes, por lo que estas reglas DROP están en la cadena PREROUTING de la tabla mangle, por lo que se eliminan antes de llegar a las cadenas INPUT y FORWARD de la tabla de filtro. Presumiblemente, esto también elimina el tráfico a la interfaz loopback. Las reglas de ENTRADA, SALIDA y ADELANTE ACEPTAN el tráfico apropiado antes de una regla DROP predeterminada en cada caso. La depuración aquí ha implicado comentar las reglas DROP de zeroconf, que restauran el arranque en algunos casos pero por razones desconocidas.
Curiosamente, nada de esta configuración tiene ningún efecto en el proceso de arranque cuando la máquina tiene los cables Ethernet desconectados.
La depuración continúa, pero se agradecería especialmente cualquier idea constructiva sobre lo que puede estar sucediendo y cómo lograr una instalación estable. Estoy fuera del negocio hasta que esto se resuelva.