Algún truco para acelerar el arranque en Leap15

**SergioNN** · 05-jul-2018, 10:52

Hola.
Me encontré el arranque de Leap15 más lento que nunca, y vi en el blog del amigo Benja https://www.diversidadyunpocodetodo....n-el-arranque/ algún truco que me ha funcionado.
Como le aporto yo mismo, desactivar Wicked me ha funcionado perfectamente y me ha acelerado bastante el arranque.
Ahora, me queda así:

Código:

leap15@linux-pbv8:~> systemd-analyze blame | head
          2.219s postfix.service
          1.391s firewalld.service
          1.349s ca-certificates.service
           980ms dev-sda5.device
           944ms ModemManager.service
           917ms backup-rpmdb.service
           828ms apparmor.service
           681ms display-manager.service
           613ms polkit.service
           580ms rsyslog.service

Por lo pronto, el arranque sigue siendo algo lento, pero como se ve, el cortafuegos pone lo suyo (y no pienso desactivarle nada de lo que tiene).
Lo del servicio de Modem es algo que no sé si quitarle o no.
Y de lo demás, me gustaría saber qué opinión tienen.
Saludos.

**karlggest** · 05-jul-2018, 17:28

Hola.

Hay muchos "trucos" pero por supuesto, si no viene así por defecto igual es por algo. Puedes dejarlo en unos cuatro segundos. Hay un par de artículos en inglés al respecto y hablamos de ellos en el foro hace un montón.

Cosas a probar:
*no configurar cosas como el teclado y su teclado numérico
*quitar plymouth
*ntp

https://victorhckinthefreeworld.com/...e-en-opensuse/

Salud!!

**DiabloRojo** · 05-jul-2018, 17:33

Hay un tema iniciado por Krovikan donde hablamos y hacemos experimentos, igual te interesa leerlo.

Pero la mejor manera de acelerar el arranque de openSUSE es comprando un disco SSD e instalando ahi el directorio raíz /, mano de santo.

**mikrios** · 05-jul-2018, 23:43

Hola:

Te basas en systemd, para recortar, en los pasos anteriores es mas difícil .

Por ejemplo, el 1º que tienes no te sirve de mucho y lo puedes desactivar desde administrador de servicios de yast.

Si no usas ipv6, no lo actives , idem bluethoo, no configurar nfs desde yast, dejalo en dolphin y monta en administrador de serviciós autofs (montar y conectar a demanda).

Vigila en el arranque el orden de conexión, algunas hacen 3 intentos y pueden tardae 3 minutos o mas, haciendo la conexión mas tarde, es mejor conectar primero y evitar esas esperar largas.

Un resumen de todo lo haces con systemd-analyze plot > /home/user/Imágenes/arranque.svg , eso lo ves después con firefox.idem blame, crical-chain, etc ( puedes quitar de 28 a mas de un minuto).

También las cosas programadas que estén en tiempo fuera de sesión o que no uses pc, o que se hagan en segundo plano, ejemplo cuando veas una peli o navegues (cron, mantenimiento, servicios de rotate, etc) , para ello mira sus configuraciones en yast y en /etc; también limita snapper si lo usas, limita journal, etc, eso ya no corresponde en el arrranque (pero con cpu de variós núcleos e hilos, no te das cuenta) .

Si no usas wifii desactiva las verificaciones,conexiones,wpa, en algunas de mis placas suelen tener las 3 conexiones, sin contar bluethoo.Resumiendo, puedes reducir lo que respeta al espacio de usuario y ha veces en firware

Código:

FRANK-Z87-D:~ # systemd-analyze
Startup finished in 16.471s (firmware) + 8.011s (loader) + 3.638s (kernel) + 2.258s (initrd) + 24.086s (userspace) = 54.466s

Los 8 de firw, a veces se pueden quitar.

Código:

FRANK-Z87-D:~ # systemd-analyze blame
          9.108s btrfsmaintenance-refresh.service
          8.166s home.mount
          6.466s apparmor.service
          5.576s wicked.service
          2.900s dev-sdb2.device
          2.594s systemd-journal-flush.service
          2.184s ModemManager.service
          2.103s SuSEfirewall2_init.service
          1.353s lm_sensors.service
          1.137s logrotate.service
          1.031s display-manager.service

Como ves algunos no están y el btrfs , creo que lo puedo configurar para otros días o en otros momentos.. ( versión leap 42.3) .

firmware no siempre aparece en systemd, salvo determinadas circunstancias (creo que en /boot o en otro sitio se puede quitar, ejemplo /etc, por ahora no le di importancia y no lo mire, por lo que no lo se) .

Edito: puedes quitar el primero que aparece en tu log, en gestión de servicios de yast, inabilitalo y ponlo en no activo ( te ahorras 2,2 seg) y si usas inxi no actives lo de la temperatura del HD, esté corre en 2º plano, uses o no el comando (ahora no se si lo han cambiado) , también si tienes discos nuevos quita smartd, ya eso lo puedes activar en bios, pero algún programa, que lo usa, no podrá ver ese dato (ejemplo partition manager de kde) .

Saludos cordiales .

**Krovikan** · 06-jul-2018, 00:23

Con la boca abierta me quedé al ver los 54seg de @mikrios.

El mio:

Código:

systemd-analyze     
Startup finished in 2.070s (kernel) + 1.729s (initrd) + 26.476s (userspace) = 30.276s

Código:

systemd-analyze blame
         20.148s minidlna.service
          4.892s wicked.service
          2.197s bootchart2-done.service
          1.592s upower.service
           882ms display-manager.service
           743ms apparmor.service
           521ms vboxdrv.service
           392ms dev-sda1.device
           355ms postfix.service
           355ms mnt-juegos-wine.mount
           346ms systemd-journal-flush.service
           235ms ModemManager.service
           210ms copias.mount
           192ms home.mount
           139ms udisks2.service
           121ms systemd-vconsole-setup.service
           119ms polkit.service
            97ms systemd-logind.service
            86ms systemd-modules-load.service
            84ms systemd-fsck@dev-disk-by\x2duuid-747c8c0e\x2dc84b\x2d44e0\x2db2bf\x2daf441b9d8698.service
            80ms ntpd.service
            79ms user@1000.service
            72ms rc-local.service
            72ms alsa-restore.service
            72ms mcelog.service
            72ms nscd.service
            67ms systemd-udev-trigger.service
            66ms systemd-fsck@dev-disk-by\x2duuid-87887b36\x2db849\x2d4373\x2d96b3\x2db8239df90378.service
            65ms wickedd-auto4.service
            65ms systemd-udevd.service
            64ms wickedd-dhcp6.service
            60ms wickedd-dhcp4.service
            55ms systemd-user-sessions.service
            54ms iscsi.service
            53ms vboxes.service
            44ms var-lib-named.mount
            42ms user@481.service
            42ms \x2esnapshots.mount
            42ms var-lib-mysql.mount
            41ms boot-grub2-x86_64\x2defi.mount
            38ms avahi-daemon.service
            38ms wickedd.service
            34ms var-crash.mount
            33ms srv.mount
            31ms wickedd-nanny.service
            30ms usr-local.mount
            27ms var-lib-pgsql.mount
            26ms dev-disk-by\x2duuid-d6572c9f\x2d8331\x2d4a6b\x2dbe2e\x2df695f347ca2a.swap
            25ms var-spool.mount
            24ms var-opt.mount
            24ms var-lib-mariadb.mount
            24ms var-lib-libvirt-images.mount
            23ms opt.mount
            23ms boot-grub2-i386\x2dpc.mount
            23ms tmp.mount
            22ms plymouth-start.service
            22ms var-log.mount
            22ms var-cache.mount
            21ms var-lib-mailman.mount
            20ms var-tmp.mount
            19ms var-lib-machines.mount
            19ms systemd-journald.service
            18ms auditd.service
            18ms bootchart2.service
            16ms plymouth-read-write.service
            13ms sys-kernel-debug.mount
            13ms systemd-remount-fs.service
            12ms dev-hugepages.mount
            12ms systemd-tmpfiles-setup.service
            11ms dev-mqueue.mount
            10ms systemd-tmpfiles-setup-dev.service
            10ms dracut-shutdown.service
             9ms systemd-fsck-root.service
             9ms rtkit-daemon.service
             7ms systemd-tmpfiles-clean.service
             6ms systemd-udev-root-symlink.service
             5ms sys-fs-fuse-connections.mount
             5ms systemd-update-utmp.service
             4ms systemd-sysctl.service
             4ms systemd-random-seed.service
             3ms kmod-static-nodes.service
             3ms systemd-update-utmp-runlevel.service

Saludos

**karlggest** · 06-jul-2018, 17:04

Hola.

Os recuerdo que esto mola probarlo varias veces, para saber el promedio. En un arranque particular, puede, por la razón que sea, suceder o no algo que modifique el resultado (por ejemplo, revisar la partición, problemas con la respuesta del router al configurar la red, etc.).

Los artículos enlazados por victorhck son viejos pero aun aplican más o menos. Lógicamente, la configuración por defecto tiene su razón de ser y modificarla generalmente implicará renunciar a cosas.

Salud!!

**gvcastellon** · 07-jul-2018, 00:00

Iniciado por karlggest

Hola.

Os recuerdo que esto mola probarlo varias veces, para saber el promedio. En un arranque particular, puede, por la razón que sea, suceder o no algo que modifique el resultado (por ejemplo, revisar la partición, problemas con la respuesta del router al configurar la red, etc.).

Salud!!

...de acuerdo con @karlggest, por ejemplo este no seria buena referencia debido a que hubo una actualización del "kernel". ...por cierto no se si esto lo hace cada vez que se actualiza el "kernel".

Código:

systemd-analyze blame 
         58.501s purge-kernels.service
         20.259s wicked.service
         12.511s backup-rpmdb.service
          9.150s apparmor.service
          8.256s systemd-journal-flush.service
          6.834s btrfsmaintenance-refresh.service
          6.760s ca-certificates.service
          5.568s ModemManager.service
          5.290s lvm2-monitor.service
          4.317s display-manager.service
          4.152s polkit.service
          3.587s wickedd-auto4.service
          3.540s plymouth-quit-wait.service
          3.526s wickedd-dhcp4.service
          2.937s initrd-switch-root.service
          2.862s wickedd-dhcp6.service
          2.697s rsyslog.service
          2.663s avahi-daemon.service
          2.516s nscd.service
          2.235s home.mount
          2.059s chronyd.service
          1.982s kbdsettings.service
          1.813s plymouth-start.service
          1.478s postfix.service
          1.242s mcelog.service

Salud.

**SergioNN** · 07-jul-2018, 10:24

..por cierto no se si esto lo hace cada vez que se actualiza el "kernel".

Tú, por lo pronto, procura no estar trabajando con discos externos si el kernel se está actualizando, elige hacer una cosa u otra, no te vayas a llevar alguna sorpresita como yo

(Que fue cuando se trabó el inicio y tuve que medio reinstalar para que me reconociera los discos)

**mikrios** · 07-jul-2018, 20:07

Hola :

Lo de 54seg. está dentro de lo normal.

Lo mencionado por @gvcastellon, es eventual, lo mismo que una ejecución de dracut, actualización de grub2, y algún mantenimiento programado en cron.

Si se sale de ahí, o si tienes un servicio programado y lo tienes apagado (nfs si lo has programado por yast, si lo tienes solo en dolphin no afecta mucho o nada,pero mejor eso que se quede colgado el pc, o tener que entrar con vim y editar fstab, etc )eso es normal , systemd hace uno o varios reintentos, pasado estos, no bloquea el sistema, si no que continúa ( pueden ser de 1,30 seg, o mas, incluso ejecuta la espera y mas tarde ejecuta el servicio, ¿falta de sincronización? ) .

Incluyo en esto el tiempo negativo del firmware , anterior a el loader y también se me olvidaba en el espacio de usuario el mantenimiento de btrfs .

Es algo por lo que hay que pasar, seguridad, ante rapidez.

En un log anterior fueron 20 segundos, pero claro en una M2 pcie, cuando en ext4, con la 13.1 arranco en 6 segundos (estando el tiempo de espera del grub2, que eran otros 6 segundos, el total arranca en 12 segundos) .

Con decir que la M2 lee a 1.5TeraBites/por segundo (1 byte= 8 bits) y escribe a 600MB/s, eso no es normal.

También lo de firmware es eventual, a veces sale y otras no (desconozco la causa) :

Código:

FRANK-Z87-D:~ # systemd-analyze
Startup finished in 30.593s (firmware) + 3.806s (loader) + 2.242s (kernel) + 2.343s (initrd) + 24.019s (userspace) = 1min 3.004s

Y lo raro en tiempo negativo, debería salir o contar desde 0 ( en algunas versiones de systemd, lo arreglan, pero en la siguiente, vuelve a estar igual ( lo mas seguro es systemd-analyze, plot, blame--> descarto critical-chain y otros, a veces no se ajustan a la realidad, tardan mas de lo que ponen) .

http://paste.opensuse.org/523613

Y no te extrañe, pruebo arquitecturas de intel con placas asus, y las mas nuevas,son para tomarme una merienda y no haber acabado, incluso las pruebas con Phoronix Test Suite , duran toda la madrugada.

En cambio coges una portátil o un equipo de hace varios años, y van como una bala ( este z87 D con 32Gb, ha estado parado 2 años, porque no rendía, y el x99 deluxe2 con 64Gb y M2, no se está comiendo un rosco, el mejor por ahora es el x79-pro, que es el mas viejo con 64Gb de ram, y otro que vendí ese era el que tardaba 6 segundos en arrancar con ssd de intel) .

Ojo las pruebas se hacen o se suelen hacer iso por iso (muchas de ellas de openQA) , también en todo tipo de raid, y con varios tipos de hardware (menos hacer ov, pruebo varias marcas ssd, wd, etc, fallo rotundo con los híbridos seagate, bueno uno defectuoso y los otros mas o menos dentro de lo normal, 197MB/s lo considero bueno, 1 de 3 teras, nuevo, fallo y se averió en la prueba )

Y si vas a usb 3.0, hay sorpresas tremendas, velocidades grandes, a los pocos segundos y después tasas de 14Kb/s como para hacer una copia en 7 días.

Actualmente, le dedico un poco de tiempo a analizar archivos y sus asociaciones, enlaces simbólicos, iconos, themas, etc y pienso o bien están de broma o falta de coordinación; arregle unos, pero otros hay que hacer un croquis y normalizarlos o ponerse de acuerdo (edite algunos y están asociados a cosas no existentes, por eso no aparecen en el lanzador, puede que sea por lo del idioma, o algún bug, otros los asocian, a temas que no tienen nada que ver, creo que hace falta una depuración y que se normalice un acuerdo, para que cada uno ponga lo mismo, no que pase por openQA, factory y lo dejen pasar así ) .

KDE4 era muy rápido, pero a la larga, podría quedar corto o falta de potencia (perdemos cosas, pero ganaremos algo en el futuro) , plasma, como tal, que lo digan los que ejecutaron las primeras isos, parecía un mac, muy rápidas (pero claro solo con aplicaciones de plasma, he probado las que hacen en suse estudio, sobre todo las de Javier y eran muy rápidas ( ademas no se si estarían usando como base, las escalables o svgz, por que la calidad de los iconos impresionaban ) .

Quien quiera saber mas sobre el tema, que se estudie un poco systemd, vamos que incluso en determinadas circunstancias, el que tarde 5 minutos puede ser normal (dependiendo de lo que lo provoque, 2 minutos y menos es lo mas corriente ) .

Edito: Lo que falle algunas de esas cosas, me refiero a temas y asociaciones, lo veo algo lógico y creo que algunos, se habrán dado cuenta que cuando cambia de tema, algunas cosas, dejan de funcionar, también puede observar en /usr/share ---> aplicaciones, como algunas, usan los mismos iconos, etc ; creo que son cosas que puedan fallar en las aplicaciones, pero no en el resultado de openQA o bien factory, o sean producto de la traducción ) .

Saludos cordiales.

**Facior** · 15-jul-2018, 10:16

Iniciado por gvcastellon

...de acuerdo con @karlggest, por ejemplo este no seria buena referencia debido a que hubo una actualización del "kernel". ...por cierto no se si esto lo hace cada vez que se actualiza el "kernel".

Código:

systemd-analyze blame 
         58.501s purge-kernels.service
         20.259s wicked.service
         12.511s backup-rpmdb.service
          9.150s apparmor.service
          8.256s systemd-journal-flush.service
          6.834s btrfsmaintenance-refresh.service
          6.760s ca-certificates.service
          5.568s ModemManager.service
          5.290s lvm2-monitor.service
          4.317s display-manager.service
          4.152s polkit.service
          3.587s wickedd-auto4.service
          3.540s plymouth-quit-wait.service
          3.526s wickedd-dhcp4.service
          2.937s initrd-switch-root.service
          2.862s wickedd-dhcp6.service
          2.697s rsyslog.service
          2.663s avahi-daemon.service
          2.516s nscd.service
          2.235s home.mount
          2.059s chronyd.service
          1.982s kbdsettings.service
          1.813s plymouth-start.service
          1.478s postfix.service
          1.242s mcelog.service

Salud.

Observo que wicked-service ocupa 20 segundos. A mi me ocurría algo parecido, me ocupaba 30 segundos y alguna vez se hacía interminable en el ordenador de sobremesa con ethernet. Observé que el portátil inicia como un rayo y no aparece el wicked-sevice en el arranque, sino el network-manager. Todo ello a pesar de haber instalado leap 15 en ambos de la misma forma. Decidí eliminar el wicked-service de este modo.

sudo systemctl disable wicked
sudo systemctl enable NetworkManager

Después reinicié y ahora arranca como un rayo. Con una sola vez que se lancen los dos comandos que cito, systemd ya no vuelve a usar wicked-service nunca más. Cuando el instalador, por defecto, no instala wicked en el portatil con wifi, supongo que no es necesario. Por si acaso, he consultado si otras distros, como Debian, usan wicked y ni siquiera aparece en sus repositorios. Todo ello prueba que es completamente prescindible.
Saludos.