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 initrden 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_handoffpará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:

¿Algunas ideas?

boot 16.04 grub2 ssd bootloader You'reAGitForNotUsingGit
fuente

Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat .

Thomas Ward

También publiqué una pregunta sobre el arranque lento, pero pasó de 29 segundos a 15 segundos, lo que ahora es aceptable para un SSD mSata III Kingfast lento en un autobús Sata II: askubuntu.com/questions/864277/…

WinEunuuchs2Unix

@ WinEunuuchs2Unix: ¿cómo pudo hacer que GRUB le dijera cuándo terminó de cargar initramfs?

You'reAGitForNotUsingGit

@AndroidDev No hice nada especial aparte de configurar el gráfico de arranque y usarlo 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 plymouthdno estoy seguro.