Un arranque regular a través de GRUB (sin recuperación) se detiene alrededor de 75 segundos en el registro dmesg.
dmesg no se guarda durante este proceso (veo registros de dmesg anteriores como .gzen /var/logpero no los de los intentos fallidos de arranque)
Por lo que puedo ver, puede haber el final de un seguimiento de pila para los controladores de gráficos Radeon.
Esto parece suceder justo antes de que los sistemas de archivos se monten correctamente (alrededor de 30 s), la inicialización de Bluetooth (30-32 s) y la inicialización de la red (32-75 s)
Hay algunas type 1400 audit(...): apparmor="STATUS" operation="profile_*" ...líneas alrededor de los 63.
Más allá de eso, los únicos cambios a medida que continúo esperando son sky2 0000:03:00.0 eth0: rx error, status 0x402500 length 60errores que ocurren incluso cuando el sistema se ejecuta con éxito. Encontré información limitada sobre este error, principalmente apuntándome a una lista de correo sobre problemas del kernel 2.6 de hace años con un código de estado ligeramente diferente.
Ninguno de los terminales virtuales funciona (solo un cursor parpadeante) y la GUI no se ha cargado. SSH aún no se está ejecutando o no es accesible.
Al presionar el botón de encendido kvm: exiting hardware virtualizationno ocurre nada más (no se apaga ni se envían más mensajes que no sean los errores de sky2 cada 2 minutos más o menos).
Al mantener presionado el botón de encendido, el hardware apagará el escritorio.
Realizar el arranque seleccionando el modo de recuperación en el menú de GRUB y presionando reanudar permite que el sistema arranque normalmente, aunque sea inconveniente ya que requiere la intervención humana para arrancar.
Sospecho que esto podría tener algo que ver con los controladores gráficos (Radeon de código abierto, un cambio reciente de fglrx ya que el último núcleo no es compatible con los controladores propietarios de ATI) o smbd / nmbd que no se inician (también en el arranque de recuperación , pero no afecta el arranque allí).