Es un problema al que todos nos enfrentamos en algún momento. Tu PC arranca lento y no sabes la razón pero resulta muy molesto, sobretodo si lleva más de 4 minutos en arrancar cuando estás usando un disco SSD de ultima generación. ¿Qué está pasando? ¿Cómo detectar el problema y cómo darle solución?
En Ubuntu y otras distribuciones derivadas es posible hacer un rápido análisis para detectar las posibles causas. En mi caso el tiempo para llegar al escritorio pasó de unos 30 segundos a unos horrendos 3 minutos, lo que hizo que el arrancar mi portátil fuera una experiencia cualquier cosa menos divertida. Así que me di cuenta de que tenía que depurar esto. Ya no podía esperar más.
Problema con más detalle
Lo que sucede es lo siguiente: el sistema tarda mucho en arrancar. Esa es la parte fácil. Esta lentitud viene en dos partes. La pantalla de bienvenida (con el logo de Lubuntu) permanece allí durante mucho tiempo, y parece que el escritorio podría estar atascado. Y luego, también lleva un tiempo cargar el entorno LXDE. Una vez el sistema parece que está listo, también hay algo de retraso inicial en los primeros segundos del uso.
Manos a la obra
Necesitamos analizar el proceso de arranque del sistema. En mi caso podemos usar systemd para perfilar su proceso de arranque, obtener una lectura precisa del tiempo de arranque total y del tiempo individual para cada servicio, incluyendo dependencias y la parte crítica en la cadena de arranque (lo que significa que nada más se ejecutará hasta que se cargue cierto servicio).
Para obtener el tiempo de arranque, solo debemos ejecutar la instrucción: systemd-analyze
Lo que hace el comando es indicarnos el tiempo que necesita el sistema para cargar el firmware, el gestor de arranque, el kernel y, finalmente, la parte del espacio del usuario, que incluye todos los diferentes servicios (ocultos detrás del logotipo de la distribución). La secuencia de arranque es silenciosa y no se ve la salida detallada. A veces, esto puede ser útil, pero realmente no necesitamos eso.
Para conseguir más detalle el siguiente comando a ejecutar será: systemd-analyze critical-chain
Y aquí se ve más claramente. Por alguna razón, el sistema está esperando que algo suceda. El resultado de ejecutar este comando nos da más información sobre qué buscar luego en Internet para resolver esto, entre otras cosas.
Nota: Si prefieres verlo de un modo más gráfico siempre puedes usar el comando systemd-analyze –system plot > systemd-analyze.svg para exportar el resultado en una gráfica SVG.
En mi caso salta a la vista que nmbd.service se está tomando un tiempo extra además de NetworkManager-wait-online.service por lo que ya tenemos algo con qué comenzar a buscar nuestra solución.
Podemos incluso indagar un poco más echándole un vistazo a otro system log, /var/log/boot.log
Parece que algo más ocurre con AppArmor.
Otro comando para verificar que podemos usar es: systemd-analyze blame
En mi caso el servicio nmbd.service está relacionado con Samba y la conexión con dispositivos Windows. Como no uso nada de eso en casa, pues he decidido desactivar el servicio por no desinstalar Samba. Esto lo logré ejecutando: systemctl disable nmbd.service
Lo mismo para el servicio NetworkManager-wait-online.service. Al trabajar en un entorno standalone en realidad no necesito este servicio. Así que desde terminal lo desactivé usando systemctl disable NetworkManager-wait-online.service
Sobre el problema con Apport, estoy investigando un poco sobre las posibles causas. Por lo pronto me he decidido por desactivarlo usando las recomendaciones de este hilo. Pero me gustaría indagar más.
Ya por último queda limpiar los registros del sistema más antiguos para ahorrar algo de espacio: sudo journalctl –vacuum-time=5d
Resultado
Tras aplicar mis cambios he reiniciado el sistema y ahora todo ha vuelto a unos aceptables 40 segundos. Estoy contento con el resultado pero claro está que podría seguir afinando un poco más para bajar esta marca.
Así que decidí echarle revisar de nuevo los registros de boot.log. Esta vez prestando atención a los eventos del kernel mediante dmseg, otro interesante comando donde podemos consultar la actividad de nuestro sistema.
Allí me di cuenta que el proceso “Begin: Running /scripts/local-premount” tomaba más de 30 segundos en terminar. Una búsqueda en Google me puso sobre la pista de que esto podría ser algo fácil de resolver aplicando diferentes métodos:
Método 1:
Debemos editar el fichero /etc/initramfs-tools/conf.d/resume de manera que en donde dice “RESUME=UUID=xxx” lo reemplazamos por “RESUME=none”. Tras salvar los cambios ejecutamos desde el terminal la orden “sudo update-initramfs -u“. Esto tardará un poco pero al finalizar ya podremos reiniciar nuestro sistema para comenzar a notar el cambio.
Método 2:
Editamos GRUB: sudo gedit /etc/default/grub
Buscamos la línea GRUB_CMDLINE_LINUX y añadimos la instrucción “noresume” por ejemplo: GRUB_CMDLINE_LINUX=”noresume” y ya por último actualizamos nuestro Grub para aplicar los cambios con sudo update-grub
¿Y cual fue el resultado? 11 segundos.
Conclusión
Seguro que me he dejado muchas cosas en el tintero pero espero que hayas encontrado útil este artículo. Comenzamos con un sistema Ubuntu que de repente arranca lentamente después de una actualización, y los registros del sistema están llenos de errores, advertencias y pistas para seguir. Siguiendo estas pistas podemos aislar el problema, buscar información en Internet y asegurarnos de aplicar una solución para que nuestro sistema vuelva a estar en forma.
Fuente: ubuntizando
