Actualización 9
Decidí probar un experimento. Quité el SSD de mi escritorio y lo coloqué temporalmente en mi computadora portátil Dell Latitude. He aquí, cargó el initrd
en un orden de magnitud más rápido, reduciendo 6 segundos el tiempo de arranque ...
Estoy un poco confundido ahora ... ¿tal vez GRUB tiene un problema con el chipset de mi placa base?
Actualización 8
Entonces noté algo interesante sobre la luz de actividad del HDD. Al cargar initrd
, es casi como si la luz se estuviera PWMed en un ciclo de trabajo del 10% o algo así. Esto me hace preguntarme si la lectura de GRUB no está optimizada, ¿tal vez algo así como hacer una llamada del sistema operativo para leer cada byte en lugar de leer la imagen como una secuencia de bytes?
Actualización 7
Parece que cargar el disco RAM inicial es una gran parte del problema.
Dentro de GRUB, presioné Cel símbolo del sistema manual. Luego procedí a escribir cada línea desde mi configuración predeterminada de una en una (¡ingresar esos UUID fue doloroso!) , Y noté el tiempo que tardó el comando en completarse. Esto es lo que encontré:
- La mayoría de los comandos se completaron instantáneamente
- El comando para cargar el núcleo tardó aproximadamente un segundo
- El comando para cargar el disco RAM inicial tardó 7 segundos
Después de escribir todas las líneas del archivo de configuración, procedo a ejecutar boot
. Desde el momento en que presioné enter hasta el momento en que apareció la pantalla de inicio de sesión, me tomó aproximadamente 7.5 segundos.
Es interesante el hecho de que la imagen initrd que está cargando es de 36 MB. Entonces, si tardó 7 segundos en cargarse, ¡ entonces solo se lee a 5 MB / seg!
La luz de actividad del disco en mi torre permanece encendida durante los 7 segundos completos ...
También aquí hay un fragmento interesante de la página de Wikipedia sobre initrd :
Otras distribuciones de Linux (como Fedora y Ubuntu) generan una imagen initrd más genérica. Estos comienzan solo con el nombre del dispositivo del sistema de archivos raíz (o su UUID) y deben descubrir todo lo demás en el momento del arranque. En este caso, el software debe realizar una compleja cascada de tareas para montar el sistema de archivos raíz
Actualización 6
Nathan Osman solicitó el tiempo de arranque en modo de usuario único en el chat.
Desde el momento F10en que presiono GRUB hasta el momento en que aparece el mensaje, tarda 13 segundos.
Además, estaba hablando con Zanna y Rinzwind en el chat y ambos tienen una puesta en marcha de 8 segundos desde el momento en que presionaron el botón de encendido. Mis 20 segundos son de GRUB. Si contara el tiempo POST, ¡sería aún más largo!
Actualización 5
Ubuntu puede leer mi SSD a su velocidad máxima de 550 MB / seg ...
Actualización 4
Así que eliminé los quiet splash $vt_handoff
parámetros del comando de arranque en GRUB en mi computadora portátil (tenga en cuenta que esta computadora portátil no tiene un SSD) , y noté algo muy interesante durante la secuencia de arranque:
Se cuelga en esta línea durante 15 segundos:
[ 4.374390] init: plymouth-upstart-bridge respawnng too fast, stopped
Aquí hay una imagen (de baja calidad):
No estoy seguro de cuál es el significado de eso ...
Actualización 3
Tomé el tiempo de arranque de una de mis otras máquinas con 14.04 (tenga en cuenta que esta máquina no tiene un SSD) , y desde el momento en que presiono enter en GRUB hasta que aparece la pantalla de inicio de sesión, toma 40 segundos.
Después de presionar enter, se sienta en esa misma pantalla púrpura en blanco durante 20 segundos, después de lo cual se carga la animación de Ubuntu y tarda otros 20 segundos antes de aterrizar en la pantalla de inicio de sesión.
Miré la salida desde dmesg
, pero no puedo decir dónde terminó el arranque. Creo que terminó a los 25 segundos. Aquí están las últimas líneas:
[ 24.916824] wlan0: associated
[ 24.916852] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 25.215550] init: kdm main process (869) killed by TERM signal
[ 25.441216] vboxdrv: module verification failed: signature and/or required key missing - tainting kernel
[ 25.445587] vboxdrv: Found 2 processor cores.
[ 25.446142] vboxdrv: fAsync=0 offMin=0x18c offMax=0x960
[ 25.446228] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
[ 25.446230] vboxdrv: Successfully loaded version 4.3.36_Ubuntu (interface 0x001a000b).
[ 25.476940] vboxpci: IOMMU not found (not registered)
[ 33.174926] init: plymouth-upstart-bridge main process ended, respawning
[ 36.495811] init: anacron main process (933) killed by TERM signal
Si lo interpreté correctamente, parece ser un problema GRUB universal.
Actualización 2
Pude confirmar que se trata de un problema de GRUB al establecer el color de fondo de GRUB en verde mediante la línea de comando a la que se accedió presionando Ccuando estaba en GRUB.
Cuando presiono enter, aparece una pantalla verde en blanco durante ~ 15 segundos antes de que se cargue la animación de arranque de Ubuntu ...
Actualizar
Creo que el problema es que GRUB está tardando mucho en cargar la imagen del núcleo.
Pregunta
He instalado Ubuntu 16.04 en mi Samsung 850 Pro 512GB SSD, y no puedo entender por qué mi tiempo de arranque es de 20 segundos. (Desde el momento en que presioné enter en GRUB). Tenga en cuenta que los 20 que estoy haciendo referencia son 17 en la pantalla de inicio de sesión y luego otros 3 en el escritorio)
Además, no estoy seguro de si esto es relevante o no, pero:
- Ubuntu está instalado en modo MBR, porque desprecio a UEFI.
- Tengo instalados los controladores propietarios de Nvidia
Mirando la imagen generada porsystemd-analyze plot > bootimage2
, ¿mi inicio aparentemente tomó 3 segundos?
Y mirando dmesg
, mi inicio aparentemente tomó 4 segundos. ¡Pero lo cronometré con mi cronómetro y me tomó 20 segundos! (Sin incluir el tiempo POST) Nuevamente, tenga en cuenta que el 20 al que me refiero es 17 en la pantalla de inicio de sesión, y luego otros 3 en el escritorio)
Así es como va la secuencia de inicio:
- ENVIAR
- GRUB cargas
- Comienzo mi cronómetro cuando presiono ENTER
- Me sale una pantalla morada en blanco durante ~ 15 segundos
- Veo la animación de arranque de Ubuntu durante dos segundos
- Aterrizo en la pantalla de inicio de sesión
- Detengo el cronómetro
- Ingreso mi contraseña, presiono enter y vuelvo a encender mi cronómetro.
- Después de 3 segundos aterrizo en el escritorio
- Paro mi cronómetro nuevamente.
Aquí está la salida completa de dmesg
: http://paste.ubuntu.com/23955108/
Y aquí están las primeras líneas de la salida de systemd-analyze blame
:
365ms dev-sda5.device
327ms networking.service
287ms accounts-daemon.service
286ms ModemManager.service
233ms systemd-logind.service
216ms apport.service
213ms grub-common.service
209ms ondemand.service
200ms irqbalance.service
183ms speech-dispatcher.service
178ms apparmor.service
160ms gpu-manager.service
148ms thermald.service
148ms pppd-dns.service
146ms systemd-user-sessions.service
142ms alsa-restore.service
140ms console-setup.service
137ms rsyslog.service
105ms NetworkManager.service
104ms upower.service
102ms avahi-daemon.service
100ms systemd-udev-trigger.service
Estas personas tienen el mismo problema:
- https://ubuntuforums.org/showthread.php?t=2325045
- https://www.bleepingcomputer.com/forums/t/598260/booting-ubuntu-tempomporary-stuck-on-a-purple-screen/
- Y parece que incluso las personas con ARCH tienen este problema ...
¿Algunas ideas?
systemd-analyze blame
. La parte extraña es que Grub estaba atrapado en "cargar el disco RAM inicial" durante unos 10 segundos, cuando debería ser una fracción de segundo debido al tamaño del archivo. Entonces el retraso simplemente desapareció. Tal vez fue una actualización del kernel? Tal vez los cambios que hice plymouthd
no estoy seguro.