Estoy intentando depurar un inicio (advenedizo) del sistema fallido/colgado en 14.04.2 LTS. root es un sistema de archivos ext4 en un contenedor luks. Los sistemas de archivos están en estado limpio.
El proceso de arranque se detiene después de upstart-socket-bridge (no necesariamente después de ese servicio específico, por ejemplo, cuando se instaló cups-daemon, se detuvo después de eso). init -vTampoco es muy útil. La única entrada de registro que no registra simplemente el inicio/detención de varios servicios es una sobre udev justo antes de init.
Begin: Running /scripts/init-bottom ... done.
udev exit failed --rc=2
(Editar) Inicialmente, volver a montar el rw raíz parecía conducir siempre a un inicio limpio, pero el hecho es que es un poco impredecible y había fallado y arrancado exitosamente de cualquier manera. ¿Qué?
Observación: Todo parece estar bien, el sistema simplemente no vuelve a montar la raíz grabable ni continúa con el arranque.
P:¿Cómo puedo saber qué servicio tiene la culpa de que el proceso de arranque se atasque?
Actualización: generar un segundo shell a través de getty one se puede ejecutar initctl listdespués de que cuelga, estos son los trabajos en ejecución
mountnfs-bootclean.sh start/running
udev start/running, process 438
upstart-udev-bridge start/running, process 432
plymouth start/running, process 122
resolvconf start/running
ssh start/running, process 767 <-- this one was manually started
mountall start/running, process 337
mountkernfs.sh start/running
mountnfs.sh start/running
bootmisc.sh start/running
upstart-socket-bridge start/running, process 745**
cryptdisks start/running
mountdevsubfs.sh start/running
mtab.sh start/running
network-interface (lo) start/running
network-interface (eth0) start/running
plymouth-ready (startup) start/running, process 315
plymouth-upstart-bridge start/running, process 316
mountall-bootclean.sh start/running
network-interface-security (network-interface/eth0) start/running
network-interface-security (network-interface/lo) start/running
Actualización 2:
- Reinstalar advenedizo y todos sus paquetes dependientes (es una molestia y) no tiene ningún efecto.
- Usando la segunda consola, puedo usarla
init 5para que el sistema atascado continúe arrancando normalmente. - el sistema ahora se atascó incluso si volvía a montar manualmente el rw raíz (o usé el parámetro del kernel rw). Mi observación inicial de que forzar la escritura raíz soluciona el problema es incorrecta.
Solución alterna:
Parece ser ureadaheadculpa. Purgarlo resultó en 5 botas limpias sin ningún problema. Dejaré la pregunta (y las 100 repeticiones adicionales) abierta para cualquiera que esté interesado o conozca la respuesta a la pregunta original: ¿Cómo, si no fuera por una prueba aleatoria, podría haber resuelto esto?
Respuesta1
Como referencia, los pasos de depuración (fallidos) que probé, que sin embargo pueden ser útiles para otros:
- obtenga otro sistema similar a Debian que arranque (por ejemplo, un ubuntu en vivo en una memoria USB de arranque) y realice cambios de configuración o software en el sistema examinado usando chroot. use qemu-static para poder hacer esto en un sistema con arquitectura diferente.
- instale un shell independiente como
sash, luego cambie la línea de comando de su kernel (use la tecla e en grub o edite grub.cfg/cmdline.txt) y agregueinit=/bin/sash, reinicie, examine la situación en ese shell y solo entonces utilíceloexec initpara continuar arrancando. - utilizar
initcon el-vinterruptor para aumentar el registro - montar el sistema de archivos raíz con capacidad de escritura temprana (por ejemplo, agregar 'rw' a la línea de comando del kernel,
mount -o remount,rw /antes de ejecutar init); esto permite realizar más registros - examinar
/var/log/upstart - inicie una terminal adicional en tty2 antes de ejecutar init, por ejemplo
getty -n -l /bin/bash 38400 tty2 &, esto ayuda a examinar el estado en el que se encuentra el sistema (por ejemplops -Af,iotop) - utilizar
initctl listpara determinar qué servicios se encuentran en qué estado