Si durante la instalación de openSUSE 15 seleccionaste el sistema de archivos Ext4, en lugar de Btrfs, es posible que al sistema le lleve demasiado tiempo en arrancar. Aquellos que asumen la configuración por defecto (Btrfs como sistema de archivos) no tienen este problema. Sin embargo, no hay que preocuparse, como otros problemillas que nos podemos encontrar en las distribuciones GNU/Linux, tienen fácil solución. Es muy simple, pero me extenderé un poco con objeto de que sirva de ejemplo de cómo un simple usuario de escritorio puede solucionar este tipo de eventualidades.
Contenidos
¿Por qué openSUSE 15 se demora en el arranque?
El problema surge porque en el arranque puede que estén habilitados algunos servicios relacionados con el sistema de ficheros por defecto. Pero como no hay particiones Btrfs, el sistema de gestión de arranque no está del todo preparado para tal eventualidad. Resultado: una demora que llega a alarmar al usuario. En mi caso el sistema tardaba entre 2 y 5 minutos.
¿Cómo detectar que este es el problema?
openSUSE, como en otras muchas distribuciones, utiliza Systemd como gestor de arranque; es un administrador del sistema y de servicios. Así que si se demora el arranque aquí puede estar problema. Y nada como systemd-analyze para evaluar el proceso de arranque con el fin de mostrar qué unidades son las que están ocasionando la demora. Sobre todo esto pueden consultar el siguiente artículo para más detalles: «Algunas herramientas para analizar y gestionar la duración del arranque del sistema en distribuciones GNU/Linux que utilizan Systemd».
Antes de conocer el motivo por el cual se demoraba tanto el arranque ejecute el siguiente comando que me ofrece los tiempos de carga de sólo los servicios que más están interviniendo:
# systemd-analyze blame | head
31.098s display-manager.service
30.578s plymouth-quit-wait.service
18.453s wicked.service
7.122s backup-rpmdb.service
803 ms btrfsmaintenance-refresh.service
684 ms ca-certificates.serviceNota: como es un comando que solicita información no es necesario ejecutarlo como superusuario.
Al observar el listado, no fueron los que más tiempo empleaban (31s, 30s, 18 s) los que realmente me llamaron la atención. Fue el quinto, que empleaba bastante menos: 803 ms. Se trata de btrfsmaintenance-refresh.service, y me sorprendió porque el sistema de ficheros que tengo en openSUSE es Ext4 y no Btrfs, que es el que se encuentra por defecto en esta distribución durante la instalación.
Además, he comprobado anteriormente que en ocasiones un servicio en concreto no sólo puede demorar el arranque, sino que también puede influir negativamente sobre otros servicios.
De hecho, cambié el Display-manager de openSUSE (Brisa de openSUSE) por Brisa de KDE Plasma; este es el que tengo en Debian sin problemas. Bien pues la demora seguía siendo excesiva.
La solución: inhabilitar btrfsmaintenance-refresh.service
La solución, obviamente, estaba en inhabilitar btrfsmaintenance-refresh.service y, en su caso, también otros servicios relacionados. Para acometer esta acción disponemos de al menos dos herramientas:
Gráficamente con YaST
En YaST tenemos un módulo que tiene la misión concreta de explorar y gestionar todos los servicios. En concreto “Administrador de servicios” que está en “Sistema”.
Efectivamente, había varios servicios relacionados con Btrfs que estaban Inhabilitados e Inactivos (esto es obvio), pero uno btrfsmaintenance-refresh estaba “Habilitado. “
Solución: señalarlo con el puntero y picar en “Habilitar/Inhabilitar” para que se muestre, finalmente, “Inhabilitado”.
En consola con systemctl
Igualmente de sencillo. Simplemente abrir consola como superusuario y lanzar el siguiente comando:
# su (contraseña) # systemctl diseable btrfsmaintenance-refresh.service
Comprobando la eficacia de la solución
Después reiniciamos el sistema y volvemos a interesarnos por la evolución del proceso de arranque con dos comandos en consola:
# systemd-analyze Starup finished in 5.770s (kernel) + 1.562s (initrd) + 20.551 (userspace) = 27.884s # systemd-analyze blame | head 18.464s wicked.service 1.170s dev-sda8.devide 578ms display-manager.service 529ms media-Datos2.mount 518ms media-Datos1.mount 440ms postfix.service
El tiempo ha descendido considerablemente a unos 28 segundo, además se mantiene prácticamente constante; ya no oscila tanto de una sesión a otra. Tiempo que para mi es asumible, soy una persona paciente.
Otra cuestión a indagar
No obstante, me intriga. Ese tiempo es entre 3 y 2 veces más que el que emplean Debian 9 y Kubuntu 18.04. En todas el servicio que más consume es el gestor de red. En openSUSE es Wicked -aunque está también instalado NetworkManager pero “Inhabilitado”-; mientras que en Debian y Kubuntu es NetworkManager. En realidad no me molestan esos 28 segundos, pero este asunto despierta mi curiosidad. Lo estudiaré y si llego a alguna conclusión interesante ya lo escribiré aquí.
Saludos flamencos,
27 ideas sobre “OpenSUSE 15 se demora en el arranque enormemente y tengo Ext4 como sistema de ficheros: Fácil solución.”
gracias por compartir el truco… echaré un vistazo a lo que mencionas, también yo uso Ext4!
Happy hacking!
Es posible que ese servicio no este activo en todos los casos, y dependa de distintos factores. ¿A ver qué te encuentras?
Saludos flamencos,
Intrigante e interesante, a veces con el apuro, los chicos de Suse se les olvida realizar las pruebas pertinentes.
Imagino que tener una fecha concreta de lanzamiento tiene que ser algo estresante. Por lo demás, openSUSE 15 me está funcionando muy bien.
Saludos flamencos,
Hola Benjamín. También uso ext4 así que voy a probar deshabilitando el proceso que comentas, ahora, que lo que me aparece a mí antes incluso que wicked es: 5.933s ca-certificates.service
Veo que en tu segundo análisis ya no te aparece, lo has inhabilitado también?
Saludos
Carlos, sólo he inhabilitado btrfsmaintenance-refresh.service. Wicked no lo he tocado hasta que estudie bien este asunto. Si está por defecto en openSUSE será por algo que yo ignoro; imagino. Además, como digo los 28s tampoco son para alertarse.
Por otro lado, cundo los tiempos totales de carga son de minutos, que no de segundos. Es decir que no son normales, es porque hay algún servicio que no funciona, y “mete ruido”, de tal forma que otros servicios se “trastocan”. En el caso que expongo el servicio que no funciona está en quinto lugar y está contribuyendo a que otros tomen mucho mas tiempo del necesario. Una vez que se inhabilita el servicio que está “metiendo ruido” todo cambia. Y este es el motivo de que el resultado del segundo análisis en cuanto a los servicio que se muestran sea diferente.
Hay que tener mucho cuidado a la hora de inhabilitar un servicio, hay que tenerlo muy claro.
Saludos flamencos,
Totalmente de acuerdo y como bien dices por esperar un par de minutos en mi caso tampoco supone ninguna desesperación. Comparado a windows va como la seda por eso y más llevo unos 7 años con el Suse.
Venga saludos Benja y gracias.
OK Carlos. Saludos flamencos y a disfrutar de openSUSE
Carlos he recordado algo que quizás te vaya bien. En el artículo que escribí anteriormente sobre systemd-analyze, en el apartado 5, párrafo 5 “-En otros casos se puede tratar de un servicio …”
https://www.diversidadyunpocodetodo.com/systemd-analyze-kcm-systemadm-systemc/
Comente que inhabilitando ModemManager.service se me optimizaba el tiempo de arranque. Yo no utilizo un Modem; creo que ya nadie, o casi nadie, lo utiliza. Pero ademas, un buen amigo del blog (Petrus) comentó en ese artículo que deshabilitando ese servicio el equipo le arrancaba mucho más rápido.
Saludos flamencos,
No había leído tu artículo y me parece realmente muy interesante, ahora mismo he deshabilitado ModemManager así que voy a reiniciar y te comento.
Si no es mucha molestia he aquí mi información de los servicios que aparecen con la orden que has dejado «system-analize».
7.010s dev-sda2.device
6.017s ca-certificates.service
6.006s wicked.service
5.433s apparmor.service
4.606s chronyd.service
4.192s firewalld.service
4.076s ModemManager.service
3.929s lvm2-monitor.service
3.329s initrd-switch-root.service
3.058s rsyslog.service
A parte de ModemM que ya he deshabilitado, ¿Crees que alguno de los otros también se podría inhabilitar? Por que seamos sinceros, desesperación no hay pero a nadie le viene mal tener un equipo que arranca en cero coma jaja.
Gracias Benjamín
P.D. Creo recordar que hace años tenía en marcadores un enlace hacia una web donde daban una lista de procesos que se podían deshabilitar para mejorar el arranque de OSuse, no recuerdo si era esta tuya, la de Victorinthefreeworld o la miradadelreplicante, lo buscaré.
Amigo Carlos, la lista esa seguro que no es mía, no estoy capacitado para ello. Ya te digo que este es un tema muy delicado. Del único que tengo seguridad es del que ya hemos comentado (ModemManager.service), que es posible que como en algunos casos suponga una optimización del tiempo significativa; ya me cuenta como te ha ido. Los otros yo diría, así a golpe de ojo, que son esenciales.
Saludos flamencos,
Mira lo encontré aquí en el foro de OSuse: http://www.forosuse.org/forosuse/showthread.php?t=16771 por DiabloRojo. Pero lo dejo así tal cual y no toco nada más, que con 25 segundos de arranque me va bien, como un sabio dijo una vez:
«Nota final: Si se nos presentara una demora durante el arranque y no damos con “la tecla” -entre otras razones porque simplemente somos usuarios de escritorio, y tenemos otros muchos asuntos en los que pensar- y, además, el tiempo no es excesivo (incremento de segundos que no de minutos), también lo podemos dejar estar ¿Qué prisa hay?»
Bueno una última pregunta, crées que para un sistema operativo de escritorio es necesario tener activo apparmor? No termino de aclararme con la información que voy encontrando por la web, unos dicen que sí, otros lo contrario. Tú que opinas a modo personal?
Amigo Carlos 25 segundos, yo diría que es asumible y está de acuerdo con esa nota final ¿Qué prisa hay?. En cuanto a appamor, después de que dí unas cuantas vueltas, llegue a la conclusión de que es esencial. Aunque sobre todo, por el mismo razonamiento de esa misma nota final.
Saludos flamencos,
He probado deshabilitando tanto Wicked como Wickedd y el tiempo de arranque era similar, con el incoveniente que te quedas sin acceso a la red.
Pero bueno, los 90 segundos desde que lo selecciono en el Grub hasta que inicia la sesión después de introducir la contraseña no me parece excesivo; además los aprovecho reflexionando sobre el sexo de los ángeles o las mociones de censura.
Saludos
Hay que alarmarse, cundo el tiempo varía mucho y se trata de minutos. En el caso que expongo sobrepaso en alguna ocasión los 5 minutos. Y claro recién instalado openSUSE me alarmé y algo más. Pero en fin bien está lo que bien acaba. Sobre la reflexión yo prefiero el sexo de los ángeles; es un asunto que siempre me ha intrigado.
Saludos flamencos,
Muy bueno, me sirvió. Gracias por el truco.
Saludos canarios 🙂
Me alegro que te fuera útil.
Saludos flamencos,
También le quité el servicio Wicked, por ver qué pasaba, y lo dejé en Network Manager. (Esto, en un fijo). Y también ha funcionado sin problemas y recortado tiempo de arranque.
Gracias SergioNN, con esto de deshabilitar Wicked hay controversia, así que no está demás conocer tu experiencia.
Saludos flamencos,
Hola, y gracias por tus aportes para usuarios no técnicos de Opensuse, una distro de la que he sido incondicional durante años pero que cada vez la encuentro más pesada. Al grano.
Yo también tengo una demora bastante larga en el inicio de la distro, v.15. De hecho, la primera vez que inició pensé que se había colgado. Acompaño la información que devuelve el comando que señalas. Un saludo.
linux-rz8l:~ # systemd-analyze blame | head
29.375s purge-kernels.service
25.649s display-manager.service
24.941s plymouth-quit-wait.service
8.772s wicked.service
5.351s apparmor.service
4.627s lvm2-monitor.service
3.466s firewalld.service
3.329s ca-certificates.service
3.326s ModemManager.service
2.805s initrd-switch-root.service
Buenas tardes José Luis. Como seguro que no utilizas un “Modem” puedes deshabilitar ModemManager.service con YaST. En ocasiones, simplemente con esto se mejora el tiempo de arranque. Puedes consultar el siguiente enlace sobre el asunto del tiempo de arranque y Systemd:
https://www.diversidadyunpocodetodo.com/systemd-analyze-kcm-systemadm-systemc/
Otra cuestión más delicada es Wicked como comento en el artículo. Puede ser el responsable de demoras considerables en determinados equipos y circunstancias. Estos enlaces puede que te sean útiles:
https://www.reddit.com/r/openSUSE/comments/5mjom2/why_wicked_is_the_default_connection_manager/
https://unix.stackexchange.com/questions/170842/opensuse-switch-from-wicked-to-networkmanager-using-command-line
Suerte y saludos flamencos,
Hola otra vez, Benjamín. Igual ya voy un poco mayor o me he vuelto perezoso, pero como tenga que romper la cabeza con el software, paso olímpicamente. Máxime en una distro que se le presupone bien trabajada y pulida. En todo caso «trasteando» un poco por las preferencias y con dos toques he reducido a menos de la mitad el inicio (de unos dos minutos a 50 segundos). En las opciones de «Arranque y Apagado» cambié la opción por defecto («Recuperar Sesión Previa») por «Iniciar Sesión Nueva». Por otra parte, en las opciones del «Aspecto Visual» eliminé la «Pantalla de Bienvenida» que no necesito para nada. No sé si hay sido casualidad, pero parece otra cosa. ¡¡Saludos!!
No creo que te hayas vuelto perezoso José Luis, imagino que el tiempo te gusta gastarlo en otras cosas. Gracias por comentar tus avances, siempre pueden ser útiles. Entre las primeras configuraciones que hago siempre en KDE, una es precisamente “Recuperar Sesión Previa”, me gusta abrir el sistema todo despejado; ya arrancaré lo que en cada momento tenga que utilizar. Y la “Pantalla de Bienvenida”, además en esta ocasión no me dice mucho; la voy a eliminar yo también.
Saludos flamencos,
Hola, pues llevo varios días indagando, y descubrí, por casualidad, que el sistema, o bien por un error mío, u otro, creo una partición en el disco ssd, (sda) que no existe y su demora era desorbitante, lo había instalado en una partición del disco mecánico (sdb) y a vueltas con el problemilla, abrí el gestor (uso KDE) y en donde aparecía ¨quiet install=hd:/// resume=dev/sda3 splash=silent quiet showopts¨ puse ¨quiet install=hd:/// resume=dev/sdb5 splash=silent quiet showopts¨ actualizar los grub’s y de 3 ó 4 minutos a 23.241s que alegría.
salu2
Gracias enae por comentar esta incidencia y su solución. Siempre nos puede venir bien por si nos surge algo similar.
Saludos flemencos,
Un truqui, puedes ver lo que pasa durante el arranque mostrando el framebuffer con F2.
Muchas gracias por el truqui no lo conocía, habrá que probarlo.
Saludos flamencos,